Where Do You Start ?
When you have decided on the type of uC you need for your application the first thing you need to do is to read the docs on the development tools and then install them. Getting comfortable with the tools and the development environment is very important and time spent reading the manuals will pay off later. For simple projects the tools will most likely do the heaving lifting for you by building make files and linker command files behind the scenes. The first time you need to resolve a link error or fix a make file you will be happy you read the manuals.
It is very important to under the memory map of the uC you plan to use so you know how much RAM is available, how big the program memory is, where the memory is in the address space and where the on-chip peripherals are mapped. Understanding how to use the on-chip peripherals is often times more difficult than understanding how to program the processor. Understanding the memory layout becomes very important if and when you need to optimize what is available.
The first program I always write for a new uC system to verify I understand the uC and how the tools work is one that blinks an on board LED which most boards seem to have. This is the "Hello World" equivalent in the embedded world. Getting an LED to flash on and off on command is a milestone that signals you are ready to move on to the more complex aspects of your project. Varying the rate at which the LED flashes forces one to investigate instruction timing which may also be important to you later.
After the blinking LED I typically go on to write programs that test my understanding of the interrupt structure of a new device. I find it helpful to write the smallest programs possible that demonstrate how things work before I try to write a larger application that utilities these facilities.
With interrupt processing under my belt, I proceed to write small programs for each of the on-chip peripherals I will need for my application. This may sound like it takes a lot of time away from the project you have in mind but time spent in such a focused manner will make development easier going forward.
Finally, make sure you know how to transfer the code you have written to the target device and that your small example programs can run standalone on the target hardware without the development system attached. Standalone operation verifies the target system's power supplies are good, the system's clocks are running, and that the device is capable of running without support from external equipment.
Just about every type of device is amenable to control via a uC. Your ideas are what are important to you but here are some ideas that might make interesting first embedded projects.
Using a uC to control a model train layout. The uC might sense where on the track a train is and control various crossing signals and/or the speed of the train on various parts of the layout.
You could attempt to build a personal web server using a uC and a TCP/IP stack available from a chip manufacturer like Microchip. Writing a TCP/IP stack oneself is not a task to be taken lightly.
You could try and build a TV remote control that learns the infrared codes required by your TV.
You could build an RS-232/network bridge device for controlling serial devices over a network.
Who knows, you might design and build the next killer MP3 player.
A great source of project ideas are the application notes manufacturers provide along with their devices. For example, you can find out how one might interface a keyboard or VGA display to a uC, how one might use DSP to decode telephone tones or build digital filters. You can even find out how a uC can be used as a simple timer. And as always the web is probably the best resource of all for finding out about projects others have done that might be of interest to you.
I hope I leave you with the idea that controlling devices with a uC can be fun. If you have never attempted writing embedded software no time is better than the present to try. You just may find you like it as much or more than other types of software you have written. It also is a plus on your resume when you can show your skill set includes embedded development. And who knows, you may invent the next great, got to have, gadget that will make the learning curve all worth it.