SSL/TLS is commonly used to secure the transport, more than the authentication of the user. For user authentication it's far more common for X.509 - which is somewhat related. You'd definitely not need any form of "vendor" to generate yourself certificates using this method, this only really being required for HTTPS to allow third parties to independantly verify the fingerprint of the certificate you've been served in order to setup a TLS tunnel is from the vendor it's claimed, and used in the expected service.
Certificate is more a software feature, than an OS thing. There's only limited use in becoming a CA, I suspect it would cause more problems than it would solve long term, especially as these things are obvious targets. You don't need to be a full on CA to sign certificates, being able to deploy similar methods to self-signing with signing remote users keys for use with auth.
Mumble isn't entirely a poor suggestion, XMPP is older however - more development/bugfixes, more testing, more hours runtime without incident - and far more flexible, designed as a comms protocol more than an afterthought of multiplayer gaming, as evidenced by it's far wider adoption in many cases by "serious" firms, like google, facebook, whatsapp etc. Should be able to host that on existing resources, overheads are minimal so zero extra expense, and has ability to be operated in a de-centralised manner by way of allowing inter-server transport between users.
The only reason google have a browser is because they understood the significance of the chromium project, and what it would really mean to get the OS off of the device itself. The end goal with that being the device only really has to have enough code/power to fire up a browser and everything else happens remotely, through that browser - it only has to worry about displaying the content. Naturally, this entailed the development of the browser component first. This should lead to smaller, lower power draw devices that can do more with less. This also opens up things like software as a service at the OS level, the subscription model to which representing the most likely future of the commercial software industry. Microsoft have already started this with orrifice and have plans to move the OS to "the cloud" ASAP. As an added bonus, investing in that technology early allowed them to expand the data raped from users of their services to users of their fork of the software which will in turn take every service it connects to. "Advertising" is just one of the more pleasant uses planned for this data.
Browsers, as modern software goes, are quite tiny. Installing several different breeds should struggle to exceed 1GB, which is about 1/10th of a HiDef film packed in h264 inside and .mkv - or about 1/30th an average "AAA" game. Unless you've a seriously old machine(pre 1998) or otherwise rediculously small amount of storage accessible, it should be difficult to notice this consumption.
Midori might be worth a gander if you've not played with it, think that was forked from FF, but I could be easily be wrong.
When it comes to making a browser more secure, for the most part, "features" are what make it insecure. Commonly. Things like BeEF just wouldn't work without them. I wasn't suggesting a browser we'd had built would be secure just 'cause we'd built it, more it can be made secure by removing the additions that are not strictly required, and making sane those which are. Development speed would depend entirely on the contribution pool for the project. One person wouldn't go very fast. 1% of our population however would be able to push out updates rapidly.
With regards to A/V software generally, consider the previous history of the vendor, and their staff. Typically, the person most qualified to venture into such a role is the sort of person that has previously written virus, possibly even responsible for some breeds doing their rounds decades later, and still updating them. To ignore the glaringly obvious conflict of interest that arises here, then consider the lack of open source nature of such things. There's a reason they obfuscate it, and it's not even remotely about keeping nasties from prying into operations or giving competitiors an advantage. Clam open sources their engine, for example, and it is still resilient enough to be professionally chosen to form the backend of many solutions deployed in public facing environments, even sometimes on government systems - commonly sanitising emails but it should be good for most purposes. It's also worthy to point out that most of these things tend to operate on some sort of "fingerprint" basis - meaning it's only as good as the list of prints. Unless it's seen it before, it's useless - additionally, shady government agencies have their malwares prints removed from these lists in order to remain effective. Lists however can be augmented, missing data added - but commercially available flavours are less likely to make this easy and even harder to find the required prints.