The short answer to your question is that, to my knowledge, you cannot grow a linux software RAID partition, so RAID won't help you there, however RAID10 is a good idea for a number of other reasons and RAID0 is nearly always a bad idea if you care about your data or downtime. I see a lot of advice on the Internet about using RAID0 with EBS volumes and it's an absolutely terrible idea in all but the most exceptional circumstances.
With such a small volume set (you said 8x1GB, so 4GB usable), I would just skip all this complexity and use a single volume which you can grow up to 1TB using XFS snapshots. With only a few gigs of data, you should be able to snapshot the volume frequently enough that data recovery becomes an easy problem and you aren't going to be maxing out I/O. Alternatively, if you can afford more than your current $.80/month for your disk, just make it bigger now and don't worry about this headache for a long time. If you really meant 8x1TB instead of 8x1GB, keep reading.
I wrote an article about this a few weeks back
http://blog.9minutesnooze.com/raid-10-ebs-data/
and briefly covered this subject at Percona Live back in May:
http://www.percona.tv/percona-live/running-an-e-commerce-database-in-the-cloud
I will summarize here.
In the world of physical hardware, the ways that disks can fail is known and somewhat predictable. On the other hand, EBS volumes fail in atypical ways. You don't see disk "crashes" - mdadm will never automatically mark a disk as failed. What you get are volumes experiencing severe and irrecoverable performance degradation. Sometimes the volumes are just slow, but sometimes they completely lock up with 100% utilization and no IOPS being performed, essentially becoming unavailable. Sometimes the disk comes back to life enough to get data off of it, but sometimes not. This is what happened in the great EC2pocalypse of April, 2011.
If your RAID0 in this scenario, you will have few options. The array will be locked up and the data stuck with it. Sometimes you can snapshot the volumes in the array and restore the snapshot, but consistency is difficult to guarantee and you will have downtime - likely several hours, as writing snapshots is a very slow procedure and RAID arrays tend to be large.
However, if you RAID10 and you end up with one of these poorly performing or severely degraded volumes, all you need to do is mark the degraded volume as failed, remove the it from the array, and replace it. I have done this many many times on our active master database servers which have 10-20 volumes in a RAID10 set (don't use that many. It's overkill unless you need a 10TB array).
My proof of this goes back to my experience with EC2Pocalypse (and multiple other minor EBS outages). While some of the most popular sites on the Internet were down for 4 days, my employer experienced less than an hour of downtime in our production environment because we were able to recover the RAID10 arrays by removing the failed disk(s). Has it been RAID0 it would have been an SOL situation.
The downside is the weakest link syndrome...Performance of the array is tied to the worst performing member. The more volumes, the greater the odds that one will degrade, but that's really a monitoring problem. One could even automate the recovery, if so inclined, though I have not done so. With RAID10, you increase your odds of having a problem in the array, but also increase your odds of recovery. With RAID0, each additional drive is little more than an additional liability.
I hope this helps some.