Although I have never used the Visual Studio load test functionality I think it works in the following way:
You specify some browser types and the load testers does HTTP calls with those browser user-agent. Its not starting a real browser to make the calls, that would be to complex and consume lots of cpu and memory. The browser list on MSDN contains browsers you can't even install on a windows machine like Safari for iPhone. This leads me to think this assumption is correct. This is also how other load test tools work, like jMeter and Funkload.
So you only need new .browser files if the back-end server serves different kind of content to these user-agents. For example mobile content, localisation or browser specifics.
The .browsers file content looks like this:
<Browser Name="YOURBROWSERNAMEHERE" MaxConnections="6">
<Headers>
<Header Name="User-Agent" Value="YOURUSERAGENTHERE" />
<Header Name="Accept" Value="*/*" />
<Header Name="Accept-Language" Value="{{$IEAcceptLanguage}}" />
<Header Name="Accept-Encoding" Value="GZIP" />
</Headers>
</Browser>
Possible more header fields are supported: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
You should be able to create any combination of header settings to test any different types of content you web-server is serving browsers. I do wonder if you really need load this specific, I don't think the bottle-necks are in the different type of content, but in disk-IO and networking.