No, this will not work, for two fundamental reasons:
You cannot "encrypt with the private key and decrypt with the public key" in any meaningful sense.* And if you could, it would be totally useless, because the public key is, by definition, public — if you could decrypt with the public key, so could anyone else.
In particular, in your scheme, anybody with access to a "signed" message could decrypt the MAC key (which they need to verify the message, anyway), use that key to forge other messages, and attach the same encrypted MAC key to them.
Even if you scheme worked, it would provide no performance improvement over conventional signature schemes. Specifically, the standard way to sign messages of arbitrary length is to hash them with a cryptographic hash function, and then sign the hash value. Thus, for long messages, the performance of conventional signatures is dominated by the time needed to compute the hash value, which is approximately the same as (and, in fact, strictly less than) the time needed to apply HMAC to the same message using the same hash.**
*) Yes, I'm aware that, for the RSA cryptosystem, signature generation and verification are very similar to encryption and decryption, except with the public and private exponents swapped. This duality is peculiar to RSA, and does not extend to most other public-key cryptosystems. And even for RSA, the duality breaks once you introduce message padding, which is needed to turn "textbook RSA" into an actual secure cryptosystem.
**) HMAC does place somewhat lower security requirements on the hash function than signatures do (in particular, it does not require the hash to be collision resistant), so you could potentially use a faster and less secure hash for HMAC. That is, assuming your scheme worked in the first place, which it does not. And, given that there exist plenty of modern hash functions that are both fast and secure, you'd still be trading a lot of precious security margin for, at best, a very modest gain in speed.