You only have $6$ bits of entropy in $8$ bits of your output - in general that does not fullfill the requirements for a cryptohraphic key of being drawn uniformly random over the full range. In general, this can potentially be desastorous: You have no security guarantees, because no security proof applies any more. In the worst case such a bias in the key can completely break the system - without anyone noticing.
In a general setting however, you should also notice that those $256$ bit output of the CSPRNG are not $256$ bit any more if you encode it as Base64 and decode as ASCII. It should be $344$ bit output, and that doesn't fit any more, if a $256$ bit key is expected.
In your specific case with HMAC it is probably fine - because HMAC is equipped to handle different keylengths: The first thing HMAC does is to transform the key into the correct length. If the key is too short, it is padded, if it's too long the hash function is used on the key. You have $256$ btis of entropy in a longer string, so this should be fine.
But please note: It is unusual that an cryptographic function is equipped to handle variable keylengths, this is a lucky catch. While it should work in this case, in general it is a really bad idea to neglect the assumptions about the key. The term key implies often, that it is drawn uniformly from a specific range and considered in binary format.