In Visual Studio Team Services, what are the best practices when creating team projects?
Is it one project for the enterprise? One project per actual project? One project per team?
With TFS, I've read many recommendations to use a single giant team project with multiple areas (see Why You Should use a Single (Giant) TFS Team Project. Is it different with VSTS?
We will have mixed languages with different build processes that includes C, C#, Java, Python, etc. with a multitude of outputs including desktop applications, mobile applications, NuGet libraries that are shared, C libraries that are shared, etc.
Is it different with VSTS
No
Is it one project for the enterprise? One project per actual project?
One project per team?
It depends the detail requirement, as that article says there are benefits to isolating and separating the various assets of each project/team, creating a team project for each seems like the most intuitive way to achieve this.
However, the multiple team projects can cause significant hurdles if you wish to move data across a team project boundary, there is no easy way to move data from one team project to another.
To conclude, you can refer to that article to decide the structure of team project(s).
It depends on your exact situation. Regarding structuring of projects and teams, Visual Studio Team Services is not different to TFS on-premise.
See also this response which explains differences to consider between having a single project with multiple teams versus a multiple projects: TFS setup for one small team and multiple parallel projects
