If only that was so simple and all software used a common store... Without exceptions like java apps, apps with hardcoded ca_path, scripts which call curl with hardcoded ca_path, etc. On top of that are websockets in FF which will just fail rather than notify you about untrusted certificates. After experiencing that first-hand for a while, I wouldn't recommend this idea. It's the second greatest annoyance after enterprise web proxies.
I wouldn't install a company CA certificate on my Mac. It would theoretically allow the company to intercept all my SSL connections. I'd rather validate SSL certs for all the intranet servers manually.
Yes self-signed certificates don't work for web servers/browsers but they work great for *aaS providers.
A lot of DBaaS providers sign their server SSL certificates with an internal self-signed CA (ex: AWS for MySQL RDS[1]). You just need to retrieve the CA certificate over a secure channel (ex: HTTPS) and save it along with the rest of the DB config for your app (user/pass/host/port) so it's pinned.
This is arguably better than using the browser-CA chain as the service provider itself would need to be complicit in compromising it (vs a malicious trusted root issuing a fraudulent trusted cert for the remote server).
[1]: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_M...
Internal CA is more about expediency than anything else. It's just easier to manage trust between a lot of servers that way than by manually exchanging self-signed certs across all the permutations.
If you know you're only ever going to have a couple-three boxes using SSL, you can also just use self-signed certificates and a static whitelist. Self-signed certificates don't work at all on the public Internet, but they're just fine for internal resources, as long as you can somehow pin them.