> 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 Encoding][1] and [MD5 is 128 bits but why is it 32 characters?][2]

> 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.

  [1]: http://stackoverflow.com/questions/4278170/md5-hash-and-base64-encoding
  [2]: http://stackoverflow.com/questions/6317276/md5-is-128-bits-but-why-is-it-32-characters