Well yes, to some extent all curves are just a series of straight lines, particularly when you are dealing with pixel art. There are a couple problems with using lots of smaller polygonal sprites though. For a platform game along the lines of what I'm thinking (and we are talking small resolutions for the visible frame right now... 320x240), level sizes routinely end up being somewhere in the neighborhood of 14000x4000 pixels and can come in much larger sizes. In order to achieve the kind of curve density that is appropriate with simple approximations, we would probably have to divide them into much smaller chunks (somewhere between 8x8 and 32x32, and those are a pain in the butt to work with in levels of that scale). It's a huge sprite explosion anyway and I have some concerns about the performance in that case. The worst thing about it though is how much additional strain it puts on getting art into the game. Generally we prefer for people to be able to work with 128x128 terrain pieces, but for something of that size you can expect to have somewhat complicated geometry that has a few notable problems:
1. The automatic collision mesh generator fails to create something resembling what it should be.
2. The amount of points needed to map the whole terrain piece vastly exceeds the recommended limits given by C2 (probably not as significant of a problem since these recommendations are more likely intended for small standalone and numerous sprites).
It's also common to have over a hundred different set types of 128x128 blocks each needing to be set up separately for collision... so for this type of game the problem is really compounded.
To sum it up bluntly, no, I don't think that approach would work.
Collision masks are really the most proper way I can think of to do this. I think you are misunderstanding something about the problem though. The real-time processing component of this is very small. The simplest (IE extremely expensive as far as memory is concerned) variation of this is a boolean array of x by y where x is the x and y are those dimensions for the scene. Figuring out whether you have a collision at a single pixel is just a check against one element in the array (array[x][y] where x and y are where you are checking) to see if it's true or false. I don't think it's actually possible for any kind of collision to be computationally cheaper. It only gets expensive if you need to check a large number of pixels (which I think is why you are assuming it's so expensive). Most behaviors only need to check a handful of points. And consider how this is done with polygons... if you want to know significant details about how an object has collided with another, such as whether it was a front collision, a top collision, etc. you have to use numerous objects anyway, so the additional checks still have to be done just like they would if you were checking pixel collision at numerous positions. So for people who need advanced knowledge of the collisions there really aren't any perceivable savings using polygonal collision solving... at least assuming polygonal collision is more expensive than checking a single value in a boolean array for truth.
Forgive the intrusion, but for a looping, like in sonic, I would do it using events, and not collisions.
Maybe this year I release one sample with it, but the behind scene of a looping is something like getting their diameters, and doing the trajectory manually, using events, and doing all the exceptions, like the player releasing keys too.
Loop-de-loops are a very small piece of the puzzle. It's also one we've hit from several different angles over the years.
The problem with trying for individual math-based approaches to solving it is how varied the loops are in the first place. They aren't all perfect circles. Some are ellipsoids rather than circular. Some taper off in places. Others are just plain irregular curves that can't be solved with simple trigonometry. Even if this weren't the case though, you still have to consider that there are ways to hit them that don't involve moving through them smoothly. You still have to have the collision in place for them even constrain yourself to just loops that could be solved with simple math. What you are suggesting has been tried before back with old Click n Create engines and the results have always been unsatisfactory and hard to apply with any versatility.
It's much simpler and you'll achieve better results in the long run to just have the loops as normal geometry. Things look better when the movement always follows the same basic set of rules anyway.