As CodesInChaos mentioned in the comments, you could simply set the size of the digested block to one byte (or bit, if that is your preference). Also as mentioned in the comments, this will not necessarily work nicely with any given hashing construction.
Is it required to always split the message into blocks instead of processing bytes?
I am not sure how you would process any input without breaking it into some kind of blocks. Considering that a block can be an arbitrary size that is usually defined by the algorithm in question, a block could range from 1 bit to however many bits constitute a complete input message. One bit is a valid blocksize, one byte is a valid blocksize, and X-Y bit words for any X and Y is a valid blocksize.
So I would say yes, it is unavoidable to split the message up into blocks for processing. Input of any length that you feed into the compression function constitutes a block. This seems unavoidable, unless you simply don't compress any input. Even if you compress the entire message at once, you are still working on one block.
Is this just an artifact of the functions used internally by the hash
The blocksize influences the performance of the compression function. If you digest 512 bits at a time using X instructions, clearly this will digest data much more quickly then digesting 1 bit at a time using the same X instructions. This assumes the CPU has appropriately sized registers and instructions for operating on the desired word size - which may not necessarily be the case.