There are different types of MIMO. Those are Precoding, Spatial multiplexing, and Diversity Coding.
Precoding
The idea behind MIMO is that at the frequencies being used, the wavelength is small enough that even 30 cm apart is enough to receive the signal at different phases. As Brain said, the wavelength is about 12.5cm for 2.4 GHz. This means that regardless of how far you are from the two antennas, the delay (or phase delay) between the two antennas will always be fixed for any given angle.
You are able to take advantage of this phase difference to create beam steering. The math and actual implementation of this is complex, but the general idea is actually relatively simple. If the two signals are in phase, then you know that the source of that signal is the same distance from each antenna which means that your source has to be somewhere along the line of symmetry.
As the source begins to move around, the signal will get to one or the other antennas first and the angle from the receiver can be determined based off of the amount of delay between the two. This then allows you to setup "sectors" or beams based of off how much delay is applied to the incoming signal.
Now technically the drawing I showed is only MISO (Multi in single out), but the logic holds true when you add another antenna to create a full MIMO. Also, on the transmitting side, you can do the same thing I talked about with receiving, but instead a delay is applied to one or the other antenna to create a beam in specific direction out of the transmitter.
The accuracy of the angle in and out of each pair of antennas is determined by both the spacing of the antenna and the accuracy of electronics to produce and detect a specific phase shift.
Also things get more complex as you start to account for the fact that at some locations the signal might appear to get to the antennas at the same time but are actually 1 full cycle apart. Also there has to be a control system setup to know what direction you should be directing you beam at, especially when you have a moving device.
But to get to your question directly, it doesn't matter if your source has 2 antennas or not, it is treated the same on the receiving end. What maters is the angle that the source is from the destination. You essentially end up with a source directing its beam in the general direction of the receiver and then the receiver is steering its beam in the general direction of the transmitter.
The big advantage of using MIMO is that you are not creating a lot of extra noise for neighboring devices and so you are able to get more devices in to a small area. Also, since the signal is more directional there is less to bounce off of which results in less issues with multipath.
Bluetooth is a term that covers a protocol stack and the hardware specification required to implement radio based links between two or more devices in a standardised way. The aim is to allow consumers to be able to purchase "Bluetooth" capable devices from any vendor and that those products should function with each other without issue. Thus your Nokia mobile phone should function with a Motorola head-set or the hands-free car kit in your BMW without any issues or problems.
Allowing "anything" to connect to "anything" via the Bluetooth protocol does not always make practical sense, neither is it always worthwhile. For example, does it make sense that a Bluetooth enabled printer can connect to a Bluetooth headset? Additionally, the type of data you wish to transfer over the Bluetooth link is important to know. For example, if I wish to print something out via Bluetooth, I am more concerned that my letter is printed without error rather than how long it takes (within reason). For audio, I am more concerned that I have a stream of continuous audio without breaks, pops or crackles but if a millisecond or two of audio is lost occasionally or the signal is not 100% accurately reproduced upon arrival, I probably won't hear this. (Hence, if you are an audiophile, Bluetooth is not a choice you would consider!)
Thus, depending on what type of data and functionality is desired, the Bluetooth SIG (they write the specification) have defined different "profiles" to cover them. For a plain vanilla data connection to provide a wireless alternative to a COM/RS-232 type connected, you have the "Serial Port Profile" or SPP. For high-quality audio transfer you have the "Advanced Audio Distribution Profile" or H2DP. For low-quality telephony audio for head-sets you have the "Head Set Profile" or HSP. (see http://en.wikipedia.org/wiki/Bluetooth_profile)
So, to the Arduino BT module. Looking at the brief overview it seems to be targeted at serial data transfer and I am probably not far wrong in saying that it uses primarily the SPP profile. Thus the data rate on offer will vary wildly depending on factors such as distance, interference etc. Not an issue perhaps for wireless data, but no good for wireless audio where a 'as good as electronically possible' minimum data rate needs to be guaranteed.
Thus you need to look for a Bluetooth module that supports the A2DP profile, of which there are many (randomly found product is here http://kcwirefree.com/audio.html)
A system build up for an audio link via Bluetooth could look as follows:
Audio In/Out <-> Audio CODEC (hardware) <-> Microcontroller <-> BT Module <-> Antenna
or
Audio In/Out <-> Audio CODEC (hardware) <-> BT Module <-> Antenna
^ ^
| |
Microcontroller
Note that there are some BT modules that have all the necessary support and only require the external Audio CODEC and no microcontroller at all.
The audio CODEC is a hardware chip that converts analogue audio signals into a digital bit stream, as well as doing the reverse, which has a interface functioning similar to SPI except the clock runs continuously. Such an interface is often call I2S. They also have a real SPI interface that is used to configure the CODEC (sample rate, amplification of signals etc.) An example from Wolfson is here: http://www.wolfsonmicro.com/products/codecs/WM8731/
The microcontroller performance depends on how much of the Bluetooth protocol is implemented in the Bluetooth module. The Bluetooth protocol stack splits fairly neatly in two; below HCI and above HCI, where HCI stands for Host Controller Interface. Bluetooth implementations for PCs (as an example) use Bluetooth modules/chipsets where only HCI and below is implemented, and then rely on the the PC operating system to run the HCI and above portion of the software stack. The upper half of the stack requires a decent performance processor (own experience says 16-bit and 16MHz or better considering you probably want to run your own application too!) Many Bluetooth modules have the whole stack and much more running on them and then offer some sort of proprietary protocol over a serial interface (USART, I2C or SPI) allowing you to interact with the Bluetooth module. This protocol allows you to choose the profiles you want to use, set up a PIN code, create and destroy connections etc. In this case a simple 8-bit microcontroller with a few kBytes flash and a few hundred bytes of RAM should suffice for implementing an audio link.
Bluetooth is not a simple protocol to implement. Even the big consumer electronics manufacturers have challenges to get it right (although they have more at stake if it doesn't work perfectly all the time!)
It may seem like a cop-out/taking the easy path but I would seriously recommend using a module solution that is designed to support audio over Bluetooth such as the link already mentioned (http://kcwirefree.com/audio.html) Your chances of success are much higher and you will be able to concentrate of some other cool features you may want to implement rather than struggling to make the Bluetooth link work.
Please note: I am in no way related to any of the companies I mentioned here - they are simply the most relevant links that appeared highest on Google when I looked.
Hope this fills some knowledge holes. Feel free to add any corrections you see necessary!
Best regards, Stuart
Best Answer
If you're talking analog, and you don't mind compromising quality somewhat, and you're happy to run cable, one solution is to use baluns to ship the signals over two pairs of a cat5 cable. This approach has some advantages over an RF link in that you have your own private transmission path (the cable) so there are no licensing, channel sharing, or interference issues, but it is almost guaranteed to be lower quality. I've seen it done over about 250m of cat5 in a building's cabling, and the video was definitely degrading. Nominal maximum distance for colour video is 300m. You can buy the baluns separately and assemble them yourself, or you can find pre-assembled units with RCA and RJ45 sockets in a small box, one box at each end.
Another alternative, somewhat more expensive, higher quality, but with the potential for interference is wireless analog transmission, typically in the 2.4GHz band but depending on local licensing rules they might be available at any frequency that someone will sell them to you.