I think this is probably not the best approach.
First, you don't have to have event handlers on the individual spans, as you can have a single one on a container element and it will get fired when the event happens on any of the descendants. That saves a lot of complication in terms of canceling events and so on, as you would have to do if you had handlers on each span (remember that events fire for all the children of an element, not just the element itself).
Second, the structure of the output is based on the underlying MathML (the TeX has been converted to MathML internally). Many of the MathML elements are handled by producing multiple spans, so you would have to deal with elements that are not created by HTMLcreateSpan(), but could generate events anyway.
Third, because most of the elements used by MathJax's HTML-CSS output are spans, their heights will not necessarily correspond to the heights of their content (since spans typically have height and depth equal to that of a normal line of text regardless of their content). So the span for a fraction, for instance, will not be as tall as the fraction itself, and if you set the background color, it likely will not cover the complete fraction. (It also means the clickable regions may be a bit odd as well.)
Fourth, the routines you mention are in the deep internals of MathJax, and are not guaranteed to remain unchanged during updates. Indeed, theses routines have been substantially updated in v2.0. If you make modifications to them, you may have trouble upgrading to newer versions of MathJax, and may have to re-engineer your code. There are some parts of MathJax that are designed to be overridden by user code, but this is not one of them.
Fifth, as mentioned above, the TeX output is first converted to MathML internally, and it is actually the MathML that is being displayed. The mapping back to original TeX code is not always clear, especially if the TeX code includes macros. The mouse clicks you receive will be within the MathML structure, not the TeX structure, and so you will have to deal with the reverse maping from MathML to TeX in some way.
It is not clear from your message exactly what you have in mind as an end result. If you are trying to take an arbitrary TeX string and edit that visually, I think you are going to find that difficult. If you are working on an equation editor that can produce TeX output, that is a different story, since you will be handling TeX that you generated, not arbitrary TeX code.
if it is the latter case, then I would recommend not using TeX as your internal format (that is, don't tie the editing to the TeX string itself). I would suggest using a tree structure that more naturally represents the underlying mathematics (like MathML does), and generate the required TeX code from that (that is a pretty straight-forward process, in general). Unless the user can see the TeX string and they see that they are editing that, then I don't see any reason why you should be thinking about editing TeX strings internally. Edit the mathematical representation, and generate TeX strings from that.
In any case, the mouse click and background color changing can be done without modifying the MathJax code. I have placed an example at
There you will see two displayed equations. If you click in the first, the element you clicked on will have its background changed to red, and you will see the elements ID show up in the output area at the bottom of the page. These are MathJax internal markers, so are not very meaningful. The second equation, however, has been marked by custom ID's so that when you click on an element, a more descriptive ID is displayed. This is one method that can be used to handle the reverse mapping from the MathML back to the TeX. It uses the \cssID extension to mark each letter and operator with an identifier that you can use to map back to your internal mathematical representation. Note that this can be done without any modification to MathJax itself, but it does require a more complicated TeX string. That is another reason to not use TeX strings as your internal format. You want to be able to produce this ID-tagged TeX string to send to MathJax while you are editing the equation, but you also want to be able to produce the untagged TeX string for display to the user and as the final output of your editor.
Anyway, those are my suggestions on the topic.
Davide