Question: I'm curious about the possibility of sonifying MIDI data, which has a bitrate of 31250. The range of human hearing extends to about 20kHz, which means that the fastest bits of the signal would lie near the top of this range: not ideal for my purposes. I envision stretching the signal, and then passing the result to a small speaker. 

I'm not sure if there is a more precise term for this operation than "stretching" (I'm not super familiar with digital signal processing). At any rate, I can provide a concrete example of what I mean:

00101110100001 >> stretch by 2 >> 0000110011111100110000000011

Not unlikely, the resulting sound will seem be rather atonal/noisy, and that's OK by me. I imagine that I could accomplish this task with Arduino, but I'm wondering about whether this could be done with clever circuit design. For instance, something akin to using a 4018 divide-by-N counter IC? I recognize that the 4018 isn't exactly what I'm looking for, since this acts on a strictly periodic clock signal. 

Any ideas?

Answer: 
Since MIDI data appears to be a series of 8-bit data bytes as sent by a standard UART, you could use a microcontroller to receive the data at the standard MIDI rate, and re-transmit it at a lower baud rate. This assumes that there are sufficient gaps in the data that you won't over-run the receive buffer. 

This would probably require a microcontroller with two UARTs, as the UARTs I've used don't allow different transmit and receive speeds.
So essentially you want to make a high-frequency random bit stream (just some binary data) audible. If it is literally played as bits, without further processing, it will sounds like random 'white' noise.

To slow it down, either :

1. extend its duration, for example 1 second of bits at 31,250b/s will
last, say 3 seconds, or
2. throw some of the data away. Say 2 out of every 3 bits will get it
into an audible range

For a simple, but interesting way, to throw bits away you could use a technique used in some 'bat listening devices'. They use a shift register, initialised with a single '1' and the rest is '0's. 

The shift registers output is fed back to the input, and the output would drive the audio. The clock for the shift register is the signal. So a sequence of '1's in the signal will be merged into 1/2 clock, and a sequence of '0's will be merged into 1/2 clock.

So it tends to preserve changes. By careful choice of the length of the shift register, you can divide by a suitable amount.

To extend the duration, so that all bits are eventually played, will require memory. That could be because the MIDI data can be read and re-read, e.g. from a storage device. 

Otherwise, the 'delay line' needs enough storage to hold the data. Five minutes at 31250b/s (almost 4kB/s) = 1,144kB, i.e. over 1MB. 

It would be straightforward to make something like that with any device with enough RAM, like an R-Pi or BeagleBone black. It could be made using a MCU, like an Arduino, with the addition of some external storage. Don't use Flash memory for the storage unless you only plan on using this rarely, or the external storage is much bigger than a 'track', because Flash memory will eventually wear out.