In answer to your questions:
No. SSDs are a growing and rapidly changing market. Every manufacturer seems to have different tactics for handing error correction, garbage collection, etc. etc. I suspect about the time someone were to try and collect data on a model, the model's probably already obsolete. Manufacturers, I'm sure have that data, and I suspect they're not about to share it with anyone.
Once again, I don't think anyone knows for sure (yet.) Volumes created by spanning multiple volumes or drives is nothing new. It's been going on in Unix for probably 20+ years. Whether creating a Core Storage unit means "Yes, you really are creating a true Fusion drive" is something only Apple knows for sure.
I created a Core Storage drive and I'm using it as I write. I like to play with hardware, probably because I'm crazy. I ran tests on the SSD alone, the drive alone, and then the CoreStorage unit. The Core Storage unit outperforms a standard SSD, but it doesn't even remotely approach a standalone SSD. I would guess it's likely comparable to some RAID variants, with the best comparison being RAID 0.
I actually did some tests on the core storage unit using programs I wrote and Scannerz. Scannerz was one of the first products on the market to support Core Storage, but they do it in what (initially) appears to be an odd way. A Core Storage unit will be presented by Scannerz in 3 units: 1 for the SSD, 1 for the HD, and 1 for the entire combined volume. They recommend testing the SSD and HD separately. I presume this is because, theoretically, the HD is most likely prone to failure, but the entire volume is presented, I assume, for someone that just wants to verify there aren't any problems. It seems archaic, but it's actually not a bad idea.
When you run a scan on a Core Storage assembly using Scannerz it's blatantly obvious that a Core Storage unit isn't interjecting some elements from the hard drive into the areas of the SSD. By this I mean there's no really sophisticated, tricky, or potentially confusing interjection or remapping of blocks or sectors, it's all straight forward. When you start a scan, Scannerz will literally haul through the SSD just like it would any other SSD, and when you get to the drive limits of the SSD and hit the HD, it slows down to what seems like a crawl (compared to the SSD).
When we created our Core Storage unit we used the Phoenix tool that comes with the Scannerz to clone the original IDE to a FireWire drive, and then once the Core Storage unit was created, we used Phoenix to clone the FireWire drive to the Core Storage unit. What was interesting was that by looking at the drive space readout on Phoenix (not the progress bars which are apparently task based) you could see some of them fly at very fast rates and others work slowly. For example, to my surprise, the Applications directory transferred at HD speeds, but virtually any of the OS directories, such as /System, /Library, /lib, /usr, /var etc. etc (i.e. the core OS) appeared to transfer at SSD speeds. To me this implies that Core Storage appears to be allocating or at least initially managing what goes where, and it appears to be doing this based on core OS components. What it does later on in life, I can only guess.
Using my own programs I essentially verified that the logical volume is laid out as I described. Read/write tests in the "early" region of the unit were at SSD speeds, once past the SSD they were at HD speeds.
What's my overall opinion? To be honest, I'm not that impressed. A standalone SSD is much faster. A standalone HD is slower, but not that much slower. If I had to compare it to another drive configuration, I'd likely compare it to a RAID 0 unit. Unfortunately, the way the Core Storage volume is configured you have to rely very heavily on backups just like you would with RAID 0. For example, if the SSD or the HD goes bad on either a RAID 0 or a Core Storage setup and you have no backups, to the best of my knowledge, you're hosed.
An interesting test would be to test the overall throughput and cost of Core Storage against RAID units. With RAID you could get tons of space and speed, and the speed wouldn't be erratic, which it can be on a Core Storage unit. Of course, you need a high speed interface to accommodate the RAID unit.
One of the things I'm considering doing is going back to an SSD standalone unit, but with symbolic links to larger data areas on an external drive. This way I could transfer files that are critical to the SSD as needed if I need to go portable without the external drive and still get true SSD speed. This of course, is a PIA, which is one of the shortcomings of the prices associated with SSDS.
I hope this write up is of value to you or someone else. Thanks.