To RAID or not to RAID: SSDs and virtualization
Solution 1:
First, compiling code is known to be largely CPU bound, so don't expect improvements over a single SSD there.
In your benchmark, although the 4k 0-queue depth performance does not increase, 4k 32-queue depth (QD32) does increase pretty much linearly. IMO, this result should drive your decision.
Even though workstations are not database servers with constantly large queue depths, queue depths of 2-20 are common at least in burst during semi-intensive workstation usage - in which cases the random IO will indeed improve with RAID 0. Considering that VM add a further layer of simultaneous OS activity (and you may end up using 2+ simultaneous VM eventually), I would think that this metric should improve things in your scenario.
You can monitor your current queue depth usage in windows's Performance Monitor (Add counter...Physical Disk...Avg Read/Write Queue Depth) to get an idea.
RAID does adds a layer of complexity (and backup/recovery issues), but having a larger 240gb partition is definitely a plus IMO. Do verify about any TRIM issues before using RAID with your drives - could be a show-stopper.
Solution 2:
Hard drive speed is important to overall Visual Studio performance. Scott Guthrie touches on it well in this post:
Multi-core CPUs on machines have gotten fast enough over the past few years that in most common application scenarios you don't usually end up blocking on available processor capacity in your machine.
When you are doing development with Visual Studio you end up reading/writing a lot of files, and spend a large amount of time doing disk I/O activity. Large projects and solutions might have hundreds (or thousands) of source files (including images, css, pages, user controls, etc). When you open a project Visual Studio needs to read and parse all source files in it so as to provide intellisense. When you are enlisted in source control and check out a file you are updating files and timestamps on disk. When you do a compilation of a solution, Visual Studio will check for updated assemblies from multiple disk path locations, write out multiple new assemblies to disk when the compilation is done, as well as persist .pdb debugger symbol files on disk with them (all as separate file save operations). When you attach a debugger to a process (the default behavior when you press F5 to run an application), Visual Studio then needs to search and load the debugger symbols of all assemblies and DLLs for the application so as to setup breakpoints.
In my personal experience using a SSD has helped a lot but given that a large amount of the disk I/O is probably small random reads RAID 0 might not be a huge improvement. The other thing you might find is that virtual disk I/O eats up some of your gains.
Solution 3:
Intel Z77 supports Trim with RAID, and is one of the first low-budget chipsets to do so. But you need to specify in storage setup that you are using an SSD.