These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'.
I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.
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!
Best Answer
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.