Just thinking about how I'd make these bricks... It looks like alot of work.
You can make bricks which look like they're larger than they are, but all collision shapes must be entirely within the bounds of the brick. I made a large, static table which was actually a 2x2 brick. I haven't tried going larger than a 64xcube, but you might be able to make a brick that looks like it's a 256x64 piece of track, but isn't. Like Conan said, when placed it would place multiple bricks.
I make collision shapes for bricks using Blender 2.49b. Which is to say I export shapes from the latest version of Blender as .obj files and import them into 2.49b to be reexported as .dts shapes.
A complete brickmaking tutorial, and a tool for defining brick-grid collision would speed this project along.
I am interested in making a brick-grid collision tool, if no one else makes it.
Oh, I remembered. I fixed Support_LegacyDoors so that JVS doors don't have a colliding ghostbrick.
Support_LegacyDoors makes a staticshape datablock which uses the door's .dts shape file. The staticshape is then created when the brick is planted, and moved to the location of the brick. The bricks themselves do not have collision shapes, just a staticshape that is linked to the brick so that when the brick is deleted, the staticshape is also removed. So maybe you could do something similar for these track bricks. I don't think these staticshapes are limited to the bounds of the brick they're linked to. So you could probably make them whatever size you want.
... with that in mind you could skip the brick-grid thing entirely. Just make all of the track bricks 2x2 cubes with extra large meshes which extend outside of their bounds, and then do the collision for them using staticshapes. HackPlant, FloatingBricks, or the New Duplicator's Forceplant would make them easy to place wherever you want them. ... it's not exactly professional but it would probably work.
