You have 32GB of memory. If you have small data, EVERYTHING will be sitting in the buffer pool in RAM and drive speed will be virtually irrelevant except for tlog and tempdb activity. How much data do you have?

As for your 1M record test, again that table will sit in memory. The way to test IO speed is to run dbcc dropcleanbuffers prior to EACH access (BEWARE doing this on busy production system!!). Also, do NOT select that 1M rows back to the client - the presentation of the data will overwhelm IO performance from even the slowest disk. Do something like this:

select count(someunindexedfield) from bigtable

that will a) force a table scan and b) only bring 1 row/column back to SSMS.

Oh, and are you CPU bound by any chance? If you are (and it is EASY to do on a 4CPU box with poor schemas/indexing/code) then again your IO performance will be of little value. You could also be network bound for the BULK operations I suppose.

I would do waitstats analysis on your BULK operations to see what things are REALLY waiting for.

Yes, you can use SQLIO to test fusionIO speeds.