No, you can use the same HMAC key for any message, including an already HMAC'ed message (regardless if the HMAC value is encrypted or not).
The key in HMAC is protected by the one-way hash function used internally, so getting the key should be hard.
The collision resistance and other security properties will also prevent an attacker from generating a HMAC based on a previous HMAC value. The way that HMAC is preventing length extension attacks may be very important in that regard, because Merkle-Damgård based hashes do (generally) not protect against those. MD5, SHA-1 and SHA-2 (but not SHA-3) are all MD-hashes and vulnerable to length extension attacks.
It is much harder to proof that using the same key for AES is also secure. There may be a mathematical way of retrieving key data if the key is reused in any kind of algorithm. The chance that it is possible to use relations between the algorithms to get information on the key or plaintext message is rather small though. Still, most cryptographers would prefer to use a separate key for different algorithms unless any weakness has been ruled out (as in most AEAD schemes that use a single key, for instance).
Note that this answer is for the security of the HMAC construction itself rather than the security of the entire protocol. Attackers may still perform replay attacks where a previous message and authentication tag are resend to the receiver by the attacker. The protocol should prevent those (e.g. by including a unique message ID in the message).
As Yehuda has already hinted: it isn't apparent if this scheme would be beneficial in any way; you may perform an additional run of HMAC without security benefits. If this is the case or not depends on your use case (maybe you do want to store the decrypted plaintext message together with valid, pre-generated HMAC; that would be a strange use case, but we don't know).