Say the NSA hands Comodo an NSL and forces them to give up all their signing keys and whatever else they need. Then do this to every other CA company. What would be the side effects of this?
This is similar to what is going on in the UK right now with the Investigatory Powers Act, which gives the UK government the power to effectively perform man-in-the-middle attacks against every UK citizen. A Security Stack user @Matthew gives a great answer here explaining how something like this would occur. Although, in the UK it is more likely they would force citizens to install their certificate rather than force companies to hand over theirs.
That being said, it would be highly unlikely that the NSA could do this, CA's aren't all located under the jurisdiction of the US government.
If this ever happened they could essentially perform man-in-the-middle attacks/intercept and decrypt any HTTPS traffic of their choosing (if they got every CA to comply). They would be able to read all your HTTPS traffic. So your conversations, your banking information, anything and everything would be theirs as much as it is yours. As @John Deters mentioned in the comments, "All Bad Things could happen".
Unless it were mandated by law, there would be ways to ensure that your traffic isn't snooped on or modified, even though they hold all the keys. VPN's are one way, which could encrypt your traffic with a key they do not hold. But, this would not guarantee safety in a world where the NSA has this sort of power.
They already have this ability. As of March 11, 2011 there are 46 government owned and operated Root Certificates in the Microsoft Root Program, the US making up 7% of this. This means these CAs can sign a valid certificate for any website, and a Windows computer will trust it, even if it was originally signed by LetsEncrypt or Comodo. The US Government operates one called the Federal PKI, although it's not trusted by all browsers. There have been multiple incidents of rogue CAs signing certificates for websites they are not supposed to sign for. A rogue government CA can do the same.
There is, however, a way for websites to partially limit the ability for CAs to abuse their power, called public key pinning. A server can send a header containing a fingerprint, telling the browser to only trust that fingerprint from then on, even if a "trusted" CA later gives it another perfectly valid certificate with another fingerprint. When this is sent by the server, the browser will trust it for a period of time specified by the HTTP headers. This is called dynamic public key pinning, or HPKP (HTTP Public Key Pinning).
A problem with HPKP is that it relies on TOFU (Trust On First Use), meaning that a browser does not know which fingerprint to trust until the first time it connects. The assumption is that your first connection will be to an uncompromised server, and that in the future, you may be presented with a MITM situation. It's very good, but not perfect. Another problem is that sysadmins can risk "bricking" their website. Imagine if they accidentally send out the wrong public key, with an expiration date set to a year, or many years. Every browser which connects between that time and the time they correct the problem will, from then on, refuse to connect to their site because it regards their real fingerprint as fake. Many sysadmins don't want to risk that. The proper way to go about testing HPKP is to set the expiration date to several seconds, so at worst, you "brick" your site for a few seconds. This mentality is unfortunate, because HPKP is extremely effective at mitigating the largest problem with the CA system today.
There is also static public key pinning, where the public keys are embedded in the browsers, which has the advantage of not relying on the TOFU principal, but it's a slow and manual process, and doesn't scale well. It works very well for large companies that can afford to embed their fingerprints in the browser and track it well, like Google, but not your average website which just wants to set up a configuration and forget it.
AFAIK, because of the Patriot Act, NSA can already ask the data from any site governed by the US law. As far as I am concerned I already have no confidence in any US site to protect the data from NSA or any other US government agency. I can hardly guess why it could be worse that they can access the information exchanged if they can access the decoded information on the server...
Currently, no European governmental organization is already allowed to store its data outside Europe because of that, and they are also required to get their certificates from European issuers for the same reason.
As only US sites can be forced to used certificates originating from an US certificate issuer, it would change absolutely nothing, because non US sites could still use non US certificates unknown to the NSA, and US sites shall already disclose their data to the NSA.
Malicious usage of the keys would be noticed (we assume the NSA does this to break TLS on a large scale, for only a few targets there are much easier options than getting CA keys) and the OS developers would revoke their trust in those keys pretty fast. HPKP would protect against the attack for sites the users already connected to, or those preloaded in the browsers (Google does this for their own sites and some high-profiles ones like Facebook, Twitter, etc).
In the long term though, this would mean the end of US-based CAs (and possibly any companies that sell crypto solutions), and this is really what keeps the NSA at bay from doing this or (ab)using their own government-controlled CAs.