TFS certainly has much more potential than just as a source repository, but it's quite understandable why you would want to migrate source control first.
The migration utility of choice is generally VSSConverter.exe which allows you to map VSS paths to Team Project source control paths and is pretty well documented in this walkthrough here.
There's another tool (TFS Migration and Synchronization Toolkit) available over on CodePlex, but when I compared the two, I determined that VSSConverter has been more widely used and I think is generally accepted as being the tool of choice for VSS migrations.
It seems there are a few more answers on this thread here also.
Now, the question I think you are really asking is more about guidance on creating Team Projects and structuring?
This is a little harder to answer without knowing more about your specific circumstance. Patterns and Practices published a book on CodePlex called the TFS Guide which might help - it describes amongst many things, a suggested Team Project source control structure. It might help in giving you some guidance around how to migrate and/or remap your solution structure.
Regards to versioning and branching, check out this site here on branching guidance - it's not a bad overview of some common branching/release management techniques using TFS.
If you get through all that reading, you'll really be on top of most of the essential TFS groundwork!
First, workgroup is limited to 5 people so that path isn't available to you.
Second, and more importantly, why use TFS? (I don't ask this lightly as I am a very big proponent of TFS).
IF you decide to use TFS without purchasing the Team level visual studio products then, yes, you will need to buy a license for each TFS user which will be accessing the server. The license pricing varies, but I think it's around $450 (USD) per seat plus $2700 (USD) for the server itself in a single server installation. The Team products all come with those licenses which is why you don't have to buy them. You will need a license for anyone that accesses any type of reports, source control, etc.
The reason why I ask about why you want to use TFS is that if you are using VS Pro AND FogBuz then you are already throwing away most of the TFS features. What's left is simply source control and build management. Source control can be acquired for free with SVN and you could use something for build management like Cruise Control. Testing could be handled by nUnit.
The whole point in TFS is the fact that everything is integrated. So that when you do a check in you can tie that to a particular work item, etc. Reports are available for looking at check ins, work item tracking, bug tracking, etc.
Best Answer
They can absolutely be on different machines. Just make sure the two machines can see each other.
In the config file for the vssconverter.exe utility, you'll see this:
The area will specify where the VSS database is located. This will always be locally, since vssconverter.exe is run from the VSS server you're wanting to migrate from. If you look at the area, this is where you specify the TFS server address. The TFS address does not have to be the same machine name. As long as it is visible from the VSS server you're migrating from you will have no problems.
(I just finished a migration from a VSS server to a different TFS machine doing this.)
Hope that helps!