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
Audio In/Out <-> Audio CODEC (hardware) <-> BT Module <-> Antenna
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