This won't seriously impact the security of the key. HMAC is pretty resilient and changing the last part of the hash won't allow attacks on the a hash such as SHA-256.
Note that you only select 4 characters, of which the last one only encodes 4 bits (as it is at the end). That means you've got a check value the size of 2^22 encoded bits, i.e. a chance of 1 / 4194304 that you match a key that you didn't mean to match. If you generate a whole lot of keys you can certainly not use this to select one key from a set because of the birthday problem.
The security of HMAC is diminished with 22 bits as well, leaving you with 256 - 22 = 234 bits maximum security. Halve this for a usual setting of HMAC, so with a bit of handwaving, you're left with 117 bits.
Generally you take bytes from binary data before encoding to base 64. If you need base 64 you can separately encode the bytes afterwards.
Possible without significant reduction in quality: yes.
Advisable? Absolutely not, there doesn't seem any good reason to do this. Use a KBKDF (key based key derivation mechanism) instead to create a key fingerprint. You may use the HMAC using the normal key and an unlikely string for data for this.