dude relax, that's way overkill, did you think about your song's bit rate, and the speed at which you can access the data on your card? you should start by performing these kind of estimating calculations before allocating memory like that.
another point, SD cards can only be accessed block-by-block, and this is usually a 512 byte block, I bet you that the library already caches this block for you, and the card won't be accessed as long as you are using data from the same block
third point, I think I have already pointed you towards my tutorial on almost the exact thing you are making, I'm not sure if you've bothered with it, but if you take a look at step 14, http://www.instructables.com/id/Music-Playing-Alarm-Clock/step14/ , I have a logic analyzer session that shows you exactly how the data is sent between the SD card, the AVR, and the MP3 decoder. If you take a look in detail, you'll know exactly how long it takes for the 512-byte data block to be transfered from the SD card, and how frequently the MP3 decoder requests the data.
oh and "the whole thing just goes wrong" is not descriptive enough, you are not telling us how you know "it doesn't even write anything to the slave"
Also, you are not checking DREQ when sending the data... unless you are matching the MP3 file's bitrate exactly, you should check DREQ. Also did you ever read the VS1003 datasheet? I'm pretty sure it explicitly said that DREQ high means it can accept at least 32 bytes (meaning DREQ's falling edge means it can probably take 0 to 32 more bytes but you MUST try to stop immediantly)
I also suggest you pass the byte from myFile.read() directly into the SDI interface immediantly instead of buffering it first, since the SD card library probably already cached the data already (meaning it doesn't need to re-access the card)
about "unless the file class doesn't keep the spi port open", I hope you understand that the SPI module will always be active, with a SPI port, the CS line to a slave device is what determines whether or not a port to that slave device is "open", technically, the slave is "selected", hence the CS or SS (chip select, slave select). As a rule, a slave is always deselected when you finish talking to it, I don't think you can design the SD library without doing that or else it makes the SPI bus useless since the SPI bus is designed to support multiple slaves
There might be a music shield or something out there that uses the same decoder, and there's probably a library for that shield should it exist. If you are having this much trouble, you might consider using that instead.