How to correctly implement an archetypal encrypt-then-MAC AES-CTR + HMAC mode cipher?
You are describing encrypt-then-MAC using AES-CTR for encryption and HMAC for the MAC. This indeed results in authenticated encryption.
There may be better choices for the key derivation function, but I'm not very familiar with the options, so I'll let others comment. I don't understand why you salt the KDF when deriving the key. This just means that you will need to re-key for each ciphertext. In some ways, re-keying is better for security (maybe not here with low-entropy passwords seeding the key), but usually people like to avoid re-keying for the sake of performance.
The IV is only $8 \text{ bytes} = 64 \text{ bits}$, so you will start to expect collisions after encrypting $2^{32} =$ a few billion ciphertexts. This doesn't seem very good to me. You are devoting a full $8 \text{ bytes} = 64 \text{ bits }$ to the counter. Do you really need to support ciphertexts that are $2^{64}$ blocks long? A better balance between IV+counter  length would be preferable. For example, with a 12-byte IV and 4-byte counter, you avoid IV collisions up to 2^48 and can support ciphertexts that are $2^{32}$ blocks long ( $2^{32} \times 128 \text { bits } = 0.5 \text{ terabits} = 64 \text{ gigabytes} ).$