It is trivial to find systems where you can assign specific people to review code, of course. Plenty exist. But to guarantee that they truly read a line of code, rather than skimmed/scrolled through it? Even if they paused their scrolling on that line, it doesn't mean that they really read it, or did so with proper understanding of what it was doing. Short of placing an actual comment or question for that line (demonstrating some real interaction), it doesn't seem like an easy problem to tackle.
I think there's merit in the idea -- not tracking what a code reviewer reads but more of tracking how many times each line of code has been _included_ in a review, by being modified or maybe within so many lines of a change (like how diffs show X lines of surrounding context). The idea would be that code changes _near_ a buggy line would be more likely to draw attention to that bug and perhaps lines with less attention would be more likely to facilitate hidden bugs.
I suspect it would work out the other way round - code in a frequently modified section would be more likely to hold bugs because the requirements/understanding of that code is changing more frequently.
