I'm pretty sure you are not going to be able to do this reliably in MathML. One thing you don't mention is where the output will be used in the end. Is this for a print-based publishing pipeline, or will it end up one the web? And if on the web, will you be relying on the browser's native MathML-Core implementation, or will it use MathJax or something similar to do the rendering?
I can see some terrible hacks that could get you something close to this, but they would rely on mis-using some symbols, like using U+25DF (LOWER LEFT QUADRANT CIRCULAR ARC) for the curve below the top N and shifting things around to get the placement to work. But if you are doing this for print, you would have to verify that that character is available, and there is no guarantee that the positioning needed to get it to look right in Arbortext would be the same as needed by the printer. If you are going to use it on the web with native MathML rendering, it will have to rely on the characters available on the user's computer, and that will virtually guarantee that you will need different positioning values for different users, so it will be unreliable.
Indeed, even getting the stretchy left-right harpoons is asking for a lot. A quick test in Firefox, Safari, and Chrome on MacOS reveals that U+21CC (RIGHTWARDS HARPOON OVER LEFTWARDS HARPOON) doesn't stretch in Safari and Chrome (at least with the fonts I have installed), and is stretched by a horizontal transform that distorts the character beyond usability in Firefox. So even the basic, unembellished stretchy character is unavailable. Moreover, there is no unicode character that could be used for the downward curved arrow below the bar, though one might be able to use curve like U+25DC (UPPER LEFT QUADRANT CIRCULAR ARC) and combine it with a triangle to make an arrow head. But all the positioning will be very fragile, and my experiments across the three browsers mentioned indicate that MathML-Core is not up to the task.
If you are using MathJax to render the result rather than using the browser's native output, you could get a more reliable result across browsers, though it is still pretty fragile. In this case, you could use some CSS trickery to get the curves using borders with appropriate border-radius settings. Here is my best effort:
using the following monstrosity:
<munderover align="left">
<mo stretchy="true">⇌</mo>
<mpadded voffset="1.06em" depth="-1.06em">
<mpadded width=".075em" height="-.5em" voffset="-.5em">
<mspace width="1.5em" height=".8em"
style="border-left:1px solid; border-top:1px solid; border-radius:80% 0 0 0 / 100% 0 0 0" />
<mpadded height="-.55em" style="overflow:hidden">
<mpadded voffset=".15em" depth="-.1em" height="-.1em">
<mo lspace="0" rspace="0">/</mo>
<mpadded voffset="-.53em" height="-.53em">
<mspace width="2em" height="1.2em"
style="border-left:1px solid; border-bottom:1px solid; border-radius:0 0 0 80%/ 0 0 0 90%" />
<mpadded voffset="-.15em" height="-.15em">
I
do not recommend that you use this, or even try it out. It is only for illustration. The results of this in the browser's native MathML rendering are hopelessly broken. Even in MathJax, it requires the upcoming v4 release (in order to get the stretchy harpoons), and even then, only works in the CHTML output (as MathJax's SVG output doesn't handle the border-radius CSS styles).
So this is just me being stubborn and seeing how far I can push MathJax. Do not try this at home.
Davide