You have to make a distinction between the applicative protocol and the transport protocol. SSL/TLS is a transport protocol: it ensures some security-related guarantees (confidentiality, integrity, some authentication) for a a bidirectional stream of bytes. What these bytes mean is what the "applicative protocol" defines. E.g. in HTTPS, HTTP is the applicative protocol and SSL is the transport protocol.
Defining your own applicative protocol is completely up to you. You can botch your own implementation and have, say, buffer overflows; but, otherwise, there is nothing in the applicative protocol definition which will endanger the security guarantees offered by the transport protocol: from the point of view of SSL, bytes are bytes. There is a small caveat, though: SSL guarantees confidentiality for byte values, but the length of the encrypted data leaks. Data-length leakage has been a source of issues, e.g. the so-called CRIME attack.
Defining your own transport protocol is a bad idea. Either the applicative data does not need any of the security properties of SSL as a transport protocol, in which case the simplest and most efficient method is not to use SSL at all, just raw TCP; OR you still need some security, and "rolling your own" is a known recipe for disaster. The underlying tone is that, contrary to a widespread belief, there is little room for extra optimization in SSL: there are very few parts of the protocol which can be removed without totally breaking the security.
(What you can do, though, is to strip down functionalities: support only one cipher suites on client and server, remove unneeded extensions, and so on. This is still standard SSL/TLS, and still uses existing SSL/TLS libraries, which is the point.)