I think that's a matter of preference... If you're comfortable working directly in the SourceForge SVN (either in the trunk or on a branch) and don't anticipate a lot of maemo-specific noise in the trackers or task managers, then that is probably sufficient. It can't be too difficult to add a maemo-specific .deb file to a ufo2000 release, and Nokia 770 users will always be able to download and install a .deb file directly (i.e. without using a repository).

On the other hand, it's generally not too difficult to transfer between (for example) a maemo-specific SVN trunk in Maemo Garage and a maemo-specific SVN branch in SourceForge. And it might give your project more visibility with Nokia 770 users.

All else equal, I'd say go with whatever feels more comfortable for you.

This is, of course, always an issue in early development (whether from scratch or with a complex port). No matter how much warning you give, there are always going to be people complaining that the software is too buggy! I tend to just ignore those people that didn't pay attention to the warnings. But other people may see it as a sign to stay away from the software completely.

An alternative is to provide an invite-only test process, such that people who have clearly and sufficiently been made aware of the current situation can be allowed to test the software and provide feedback. This, of course, limits the amount of feedback you can get, but in the very early stages of development, it may be enough.

Coming from a professional usability background, though, I think that the benefit of early feedback probably outweighs the possibility of early rejection. Let the floodgates open and let people start filing new bug reports as soon as possible. Of course, if there's still a lot of basic work to be done, it makes more sense to finish that before you make a public release, since there isn't much use in collecting usability feedback if you're still buried in technical issues.