For #1, think of some (relatively) simple program that has something annoying about it, some feature you can't stand or a feature you wish it had. Now try to write that.
For #2 Don't start thinking at the code level. Think about what the goals of the application are and what are the major features. Then slowly break it down. Start at the highest level of abstraction possible. Even thinking in terms of classes is too low level to start. Think of what you're trying to represent and all the parts that go in in.
It's an overused example, but it's a good one. Take a car for example. When deciding how to build one (or a programmatic representation of one) think about what the parts of a car are. An engine, a body, a fuel system, wheels, etc. Don't worry about how to build an engine just yet, that comes later. First you need an understanding of how all the big parts come together. Then when you understand that you can start worrying about how to build an engine, what makes up a door, etc. Some parts you can get pre-made (existing frameworks, open-source projects, etc) and some you'll have to build yourself.
Break things down. Start by trying complex things as if you could get all the parts pre-made. Then if they aren't available, worry about building your own. This of course is an oversimplification and some things you do need to worry about, but in general don't get bogged down in the details too early.