About the lists themselves, I don't really see how the bitmap concept works with TBDR, because then the triangle would at least have to be partially rendered to determine which pixels it occupies, and this would basically be like early a traditional renderer with early Z-test. It would have to cover the same framebuffer regions in two completely different passes, which is not cache friendly.
rendered, as in 'ended up in a framebuffer' - no, scan-converted - yes. only for the span of the tile, though.
Also note that the polygons per second limitation is due to binning, not geometry calculations (look at the GeForce 3 which claimed much higher polygon transformation based on shaders). If binning were done per-pixel then the maximum number per frame would be a function of the size of the polygons, not the number of vertexes. So I really believe that the binning does result in lists of what triangles are in which tiles (per tile), and not per-pixel per-tile.
the number of vertices also affects the number of triangles per scene. also, per-tile binning is a function of the size of the triangles, as their size directly contributes to the numbers of triangles in the bins. nothing differes in this regard from per-pixel binning (aside from the scale) - even the maximal bin size would be the same.
anyway, regardless of any binning policies, a TBDR needs to arbitrate pixel ownership within its working tile - whether it's done through per-pixel binning, or through other means, a scan-conversion is inevitable.