I know that most hash functions today use Base64 encoding for their functions, resulting in hashes that use a-Z and 0-9, and, sometimes, other special characters. This results in 62-76ish possible values for each character, so if your hash ends up being say, 70 characters long, there are 70^62 possible combinations.
Most hashes are expressed using hexadecimal or base64 notation. The hash itself is merely a string of bits, as such is not directly expressible as readable characters.
See also MD5 Hash and Base64 EncodingMD5 Hash and Base64 Encoding and MD5 is 128 bits but why is it 32 characters?MD5 is 128 bits but why is it 32 characters?
But what if there was a hashing functioned designed to take advantage of UTF-8? From what I understand there are roughly 100,000 possible values for each character.
Again, the hash is a string of bits - 128 of them in the case of MD5, 256 in the case of SHA-256. If you were to express those bits using UTF-8, the actual hash complexity is exactly the same, but the number of characters will actually go up because UTF-8 is not an efficient text format.
Also, I know that speed is very important in hashing functions. Would this be inherently slower than a Base64 hashing function?
The hashing function would remain the same; only the translation of binary hash to textual characters would change, which would not significantly impact speed.
I know that "bits of entropy" have a lot to do with the security of a password. Does this somehow improve those entropied bits? I'm pretty confused about entropy, to be honest.
This has nothing to do with that. Entropy has to do with encryption, not hashing, and the character set used to express a hash doesn't actually impact the hashing anyway.