In my experience and based on their popularity, EBS volumes are not slow for most applications (including MySQL) especially if you are using an EC2 instance that has high IO bandwidth.
The t1.micro instances have "low" IO bandwidth, but I still wonder if you're really hitting a performance problem there. Do you have metrics on iowait that show this is the issue?
I suspect it's more likely that the t1.micro instance type is not going to be able to sustain heavy CPU activities like those that might be required in your application.
I use t1.micro with MySQL/Apache/etc. for dynamic web sites that have almost no users and it works fine, but as soon as you pile on any sort of sustained load it cuts out as designed.
Given the small memory size of t1.micro, MySQL is not going to be able to cache much of the database tables in memory, so you might get hit by its need to keep going to disk to get results. This would be a problem no matter how fast EBS IO is because it's never going to be as fast as direct memory access.
If you still think it's an EBS issue, you might try adding a caching layer so that you make fewer hits to the MySQL database. However you're quickly going to run into the memory limit on the t1.micro. Perhaps take a look at the new ElastiCache service from AWS: http://aws.amazon.com/elasticache/
If t1.micro IO is the limiting factor, you're not going to fix it with RAID as all of the EBS volumes in the RAID will be using the same IO channel together.