The approach also increases the chicken-and-egg problem: if EAX would be more widely used, it would be safer, but since it isn't widely used, it might not be as safe and thus should not be used, etc... The only way to break that cycle is by starting to use EAX.
By repeatedly reinventing your own CTR+HMAC construction, and building the code to implement it yourself, you are in fact locking yourself in a permanent state of immaturity.
Which is my real issue. I think Colin's probably right that --- in the abstract --- using HMAC (which doesn't use AES) instead of OMAC (which does) addresses an attack vector. But that attack vector is extremely unlikely, and it's OpenSSL's problem, not yours. Building your own protocol adds tens more vectors, all of which are your problem, and all of which are more likely than a key extraction attack through OMAC that will make your attacker famous.
