This is of course only an example and I'm aware of the possibility to hide the payload in a seemingly correctly designed payload. It's all about making it harder for the bad guys.
It's not merely "possible." It's easy. In fact, under HTML5, it is downright trivial.
You could issue your own root certs, install them on all your client machines, and MitM that way. But now you're playing walls and ladders with your users. By breaking WebSockets, you are giving them an incentive to find a way around your system.
The problem is that HTTP is not a "safe" or restricted protocol. It was designed to facilitate the sharing of HTML documents. It was not designed to impede uses unrelated to the sharing of documents. So, in practice, it can be used and abused in numerous ways, and avoiding this is pathologically hard.
So what can you do? Well, it depends on what you are trying to do in the first place.
If you're (say) a college, and you are trying to prevent students from consuming massive amounts of bandwidth playing online games, illegally torrenting things, etc., then track their bandwidth usage and block the top N% (for realistic N based on your network capacity).
If you're a business, and you're trying to prevent certain kinds of malware from phoning home, you should probably focus on educating your users about malware, in addition to whatever kind of non-HTTP blocking you are doing.
If you're just blocking non-HTTP because you can't think of a good reason to allow it, you should ask yourself what your threat model is. What attacks will be mitigated by this kind of blocking? What legitimate uses will stop working? Is the policy likely to annoy your users to the point that they try to circumvent it?