AES-128-CTR message integrity: Construction of HMAC (Note: This post is not about "rolling my own", but rather trying to deepen my understanding of the underlying structures.)

I'm having difficulties finding clear answers to some questions about the construction of HMACs:

Assuming we have one key for encryption and one key for message integrity checks, and we are using AES in counter mode.
As far as I understand, when creating the HMAC for a message, one should utilize all available information: The encrypted message, the key, the nonce and the counter. 


In effect, does this mean that a separate HMAC must be created for every single message, i.e. all 16 bytes?
If this is true, how would the security of a scheme evaluated in which the HMAC would be calculated over arbitrary multiples of 16 bytes, for example only every 160 bytes?
And at last, going even further, what would be the weaknesses of using merely the encrypted message (and the key, for sure) for the HMAC calculation, thus leaving out the initialization vector?


Maybe someone can shed some light on this, I have seen people doing exactly this (for example one HMAC (no counter, no nonce) for a whole file), but I'm unsure about the correctness.

Thanks in advance!
In effect, does this mean that a separate HMAC must be created for every single message, i.e. all 16 bytes?


No, you can use HMAC over the whole message with all its blocks.

Of course, that means you can't localize corruption/tampering, so if you were sending a huge message you might want HMAC smaller parts (but longer than 16 bytes or you are transmitting more hash than message), so that you can retransmit only the incorrect part.


  And at last, going even further, what would be the weaknesses of using merely the encrypted message (and the key, for sure) for the HMAC calculation, thus leaving out the initialization vector?


If you received a message $n||E_{k,n}(m)||H_k(E_{k,n}(m))$, you would only be able to authenticate the ciphertext. If an attacker had tampered with the nonce $n$, AES CTR would happily decrypt your message but give you random data.