I think the collision detection code will be the same, regardless of which method you use. You can just keep track of the path that the player has taken into the middle, and do either a point/line distance calculation, or more likely, a line/line distance calculation (http://local.wasp.uwa.edu.au/~pbourke/geometry/pointline/ and http://homepage.univie.ac.at/Franz.Vesely/notes/hard_sticks/hst/hst.html might have some useful information about point/line distance and line/line distances respectively) with each segment in the player's trail and each part of the Qix, or whatever. Of course, you could probably simplify this, since the player can only draw horizontal and vertical lines.
As far as the regions the player has filled in, the irregularity is something you can deal with, because each can be broken down into regular rectangles. In fact, this is probably something you'll almost need to do.
I was also thinking about how you might pull off the whole filled region thing, since that is going to be necessary. There are a couple of approaches that I can think of with this. Without doing any shader programming (HLSL), I think your best approach with sprites might be to divide the region into rectangles, like I said before, and draw each with a particular Texture2D. If your texture is one solid color, then this will be enough, other than you may want to draw some lines around it to make it look nicer. If, however, your texture is not just a simple color, but a pattern, you'll have to do some fancy work to get everything in the textures to line up. This will probably be a pretty big headache, so here's a couple of other approaches.
If you already know HLSL, or if you are willing to learn it, you might want to try this approach, which is similar to what you were saying about carving pieces out of the screen to show the texture. Create a texture for the entire screen that is what you want to show through. Now, it seems like I remember in Qix that if you move fast or slow, it fills in the region with different patterns. If you want that, then you'd need two screen sized textures. Next, render to a texture the current game state, using an approach like the first one, where the entire screen is colored black, and then your filled rectangles are white. So with this, you basically have a map of what has been filled in (white) and what hasn't (black). This texture will never be shown on the screen in the final version of the game, though drawing it to the screen for debugging purposes probably wouldn't hurt. If you are doing the two speeds thing, then color the two regions different primary colors - red and green would probably work well. So now you'll have your two complete texture images and you'll have a new image that basically is pointing out whether that point is filled or not, and whether it was done fast or slow. Next, you'll write a shader using a post processing effect similar to my tutorial, only the shader will be a little more complicated. The shader will have three textures, one for each fill texture, and one that is the map of your zones that have been filled in. Your pixel shader will basically just lookup the color of the pixel at the location in the zone map, and return, as a final color, the red component of of the zone map, multiplied by the color in your "slow" texture, plus the green component of the zone map multiplied by the color of your "fast" map. This way, anywhere that was green in the zone map will now be colored the same as your fast map, anything that was colored red in the zone map will be colored the same as your slow map, and anything that was black before will still be black.
If, instead, you are using the line primitives approach, it would be pretty easy to also do primitives for these regions. In addition to vertex positions, you could throw in texture coordinates, and most of the work would get taken care of for you. Now that I'm writing this down, this approach seems like it might be the easiest method, but I guess I shouldn't forget that if you do this, you'll also need to be dealing with all of the 3D stuff, like matrices and what not, so it will be a bit more complicated with respect to that. With this approach, you'd still probably want to divide the region into regular rectangles.
Now that I've been looking at it for a while, this game has quite a bit of complexity that I wasn't expecting at first. I hope you can get it going. I'd really like to see a newer version of this game. If any of my explanations weren't clear, let me know so I can clarify them, or if there is anything else I can help with.