1. It must be genuinely useful, not just an academic exercise.
2. It must be small enough in scope so that a competent OSX developer could build it in about one month full-time.
3. Bonus points if it's something I can sell.
So what should I build?
My first serious project with Cocoa was on a fairly tight timeline (a month for two apps, in fact) and I had only attempted tictactoe in Obj-C years before. What I did was immerse myself in the material and my project.
The project itself was for a museum in NYC, which has 30" touch-screens that let the visitors interact with a visual catalogue of the collection. This was a great introductory project for a few reasons.
First of all we had a great design partner. He built a very simple interface that remained constant through the entire project because he thought it out concretely before implementation. In other words, he considered the data very carefully and determined the fixed way to present it.
The second thing is that in order to import this collection's catalogue into the app, I had to build an XML parser that runs on a background thread while the UI displays a loading screen. That part was a good introduction to building an app and watching what it does in the Console, without getting into the nuances of Core Graphics and drawing, etc.. I recommend you start with something like this so that you don't get overwhelmed. It's extremely important to learn about correct memory management. Once you've got the basics, look into @property also.
From there, I had to learn about how make an application with a special kind of window, work with drawing NSViews and CALayers onto the window, learn about CAAnimation, Core Graphics, etc.
Before I built the app, I worked out my equations for laying the content on the screen and what kind of transformations I'd need to apply. Then I was able to set about building it simply.
At the time I didn't know this, but I can tell you from experience that it's very much worthwhile to look into Core Data. Even if your project is very simple and you require persistent data storage. I personally like to use json-framework and serve my app bundled JSON at initial lunchtime, with net updates after that, then do an import into my Core Data model, but this is really decided by what kind of app you want to build. I used XML for the museum project because we didn't know about json-framework yet. But it turns out that JSON translation into Cocoa objects has been much faster.
From here, you have a few options. You can either continue to develop on the desktop or you can move to iOS without very much difficulty.
If you are going to write mobile apps later and your app will interface with an existing web service, you may be better off using three20 and its http request libraries with JSON support to get data in real time. The Facebook app works like this. Actually three20 is a great option to go with for many apps. It's worth a look too, but make sure you understand UIKit as well as you can before you use three20. You still need to know UIKit to use three20 properly.
In order to determine what project you should build try to observe what kind of problems you have in daily life and what could be built to facilitate them. OS X is a wide topic and you could be talking about a GUI application, a kernel extension, or perhaps a web server. Each of them are projects which could take a month to build.
Hope this helps. Don't hesitate to ask any questions, and remember that Google and the Apple dev forums are great resources.
This is the only bit of advice in your post that I completely disagree with. Three20 may have some nice UI bits, but it is a very poorly designed framework. I say this having looked at it before and after Facebook made a big redesign of it (breaking backwards compatibility and minimally documenting the changes.)
You can't add one view without adding a dozen other classes. Its not very well documented. It adds a large amount of bloat to the binary and drastically increases compile time.. I can go on, if you like.
But besides being a free library, I used three20 in many of my recent apps because I have been working with publishers to build navigation-based apps that require things like image caching and URL navigation. A number of other features of three20 are quite welcome, despite their quirks.
I usually try to do a quick test of the framework before I integrate it into a project and guarantee that it will work, because, you're right, some of them don't behave as advertised. This is even the case with some of Apple's libraries, but I daresay their documentation is better than three20's.
Bonus points if you can encrypt and backup to Amazon S3 or something.
37 Signals do the same, but I would like to save everything locally, not to a webapp. http://37signals.com/svn/posts/585-going-inbox-zero-on-your-...
Or a small app that only runs in the menubar that will disable or enable bluetooth whenever I hit a key combo. Or when I move into or out of a certain location (Core Location exists on 10.6). Maybe if the person's on a laptop and they disconnect from a power source, turn it off, etc.
via Quicksilver.
There are known issues with Snow Leopard:
WiFi evidence source and ToggleWiFi action do not work
Bluetooth may not work, or may cause crashes
ie: http://sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs814.snc4/69481...
Bonus points if it can use photos from iPhoto!