I think a fast and secure stream cipher for TLS is desparately needed and Salsa20 seems a natural choice.
However, if I read your definition right you intend to do mac-then-encrypt in your proposal. That's most likely a terrible idea. All the trouble the CBC-modes in TLS had - Padding Oracle, BEAST-attack etc. - were due to then wrong use of mac-then-encrypt. You get all kinds of possible timing problems and even if you try to avoid them, I'd bet someone will come up with an implementation that will bring us back some variant of these attacks.
One option is to use mac-then-encrypt, however the general conclusion from most cryptographers seems to be that protocol designers shouldn't bother mixing mac and encryption at all, instead they should use well established authenticated encryption standards. However, right now I don't know if there's any AEAD-standard that can be used in conjunction with a stream cipher like salsa20.
Letting the experts speak, Matthew Green proposes to use salsa20 with a construction called poly1305:http://blog.cryptographyengineering.com/2012/10/so-you-want-to-use-alternative-cipher.html
I'm not familiar with that one, but certainly these questions should be answered before having a TLS standard.
Having a mac-then-encrypt-construction would be almost certainly a mistake and repeating the mistakes of the 90s that gave us so much trouble lately with TLS.