So what?
A SSL certificate is used just to provide end-to-end encryption, not to protect the storage.
As such, it is sort of pointless to wonder if the root certificate used by any major provider has been or is known by some federal agency or not... it is much easier to ask the owner of the server for its contents than to intercept communication.
This being said, it appears that lavabit used encrypted storage as well but there is something amiss in the way the protocol was implemented, I fear.
(I have never been using their service, so it might be I am grossly misreading things: corrections would be very welcome!)
Let me explain: as long as encryption and decryption are being performed by a remote server there is no guarantee that data might not be captured (ok ... homomorphic encryption might be going to change part of the scenario; unfortunately is far from practical nowadays and so it will be in the next 5/10 years).
There are basically three approaches I might be thinking about
1. perform decryption with a custom program on the client: the key is never sent "in clear" and the server just owns a public key to encrypt data as soon as they are received; however there is a window in which the server knows the plaintext (i.e. before writing it down to permanent storage) and might copy it.
[the sensible option is to ask people to use gpg and then rely on public servers, trusting the cryptography]
2. perform decryption locally in a javascript client in the browser. This might actually work, and with the proper setup it is also possible to use public key algorithms
(basically the user has to upload a copy of her private key encrypted with a symmetric algorithm to the server, together with a public key; upon a decryption request the server downloads the packet in the javascript app and locally decrypt it; then, once the private key is recovered it moves on to locally decrypt every single datum as stored remotely). There is the same disadvantage as in 1 here, in the sense that the server can copy the data while they are "in clear", but no special client is required. I point out, however, that in this scenario it is possible for the server to offer a compromised javascript page which also uploads the secret key as soon as decryption is required; as such the surface of attack is larger.
3. perform decryption remotely by providing a symmetric (and/or private) key. Here it is just a matter of trust between the user and the server in that the administrators are not going to either clone the data (yet this they could have done also in scenarios 1 and 2) or keep a copy of the key as provided. This is the simplest solution, but also the least safe of them all.
In summary: do not trust anybody to do cryptography in your own stead (unless you work on homomorphic encryption, of course ;-) ) and least of all to do decryption of any data; if you need secure (in the sense of 'secret') mail require all parties to use client applications providing the encryption on their own machines and not to delegate to any third party (third parties might be used to store encrypted data, though).