A couple of tips that may help.
If you only build the mojoportal-core.sln it will not have any features and may produce the result you describe.
When the setup page runs it checks for the existence of the /Data/Sites/[SiteID]/skins folder where SiteID is usually 1 on a new install. If the folder does not exist it copies the contents from /Data/skins to /Data/Sites/[SiteID]/skins
Perhaps file system permissions prevented it from completing this task. If so delete the /Data/Sites/[SiteID]/skins folder and visit /Setup/Defauolt.aspx again or copy the files manually yourself.
If you build the mojoportal-complete.sln it will build all the features and files from features in separate projects like the mojoPortal.Features.* projects are copied up to the Web folder by a post build event. ie the dlls get copied up to the /Web/bin folder and .aspx and .ascx files etc also get copied up to specific locations.
You can't use the Visual Studio Publish feature to package a build because it only deploys files that are part of the Web project. This misses all the files copied by the post build because they are not part of the main Web project. I recommend packaging builds with the free UnleashIt tool which goes by file extension rather than project membership of files.
Also, you are of course free to do as you wish but I really don't recommend that you put the mojoportal source code in your TFS repository because I don't recommend you make changes to the mojoportal code. If you do that you make it difficult or impossible to get upgrades later.
Its best to keep all customizations in your own external proejcts and only put those in your TFS repository. I recommend work with mojoportal directly from our svn repository so you can always build your custom code against the latest mojoportal code.
The way I do it with customer projects is get a clean checkout of mojoportal, add a subfolder where my customer proejcts will go. Copy the mojoportal-copmplete.sln file and rename it then drop it back in to the root. Add the custom projects to this solution and remove alternate db projects or other projects you don't plan to use. Then commit the sub folder with your custom work to your repository while keeping the rest of mojoportal using its own repository so you can easily stay up to date with the constant improvements being made in mojoPortal.
In this scenario the only important file that can't live in within either repository is the custom .sln file because it has to be in the root which would be owned by the mojoportal repo if it were checked in. Though you could commit it somewhere in your repo with instructions that it needs to be put in the root of the tree.
Hope it helps,