I don't think that the visual tag should display any graphic in the HTML form. My opinion is that the colored [nbsp] is perfect where it is within the editable text area; but it should be great if, above or below the editable text area, a warning was clearly displayed explaining what this tag means : this would avoid that unaware translators replace it with a standard space, and would also explain why it is displayed like this, with a link to a more complete page explaining the "issue" (notably why the form needs to display this tag, because of some browsers bugs replacing the actual character by a SPACE, or simply because it allows easier identification of places where NBSP is used instead of SPACE).

So the solution found for the NBSP character (replaced by the visual tag [nbsp]) should also apply to any other character that has been replaced by a visual tag in the edit form. This will apply to NNBSP (replaced by the visual tab [nbsp]), or to the BiDi controls that are sometimes needed as well within ressources for Arabic or Hebrew (they will be replaced by a visual tag as well, even if the form still displays this tag with the appropriate Bidi control directly within the <span> element that replaces the character)

For example the LEFT-TO-RIGHT MARK (LRM) character (U+2009) would also be replaced by this tag in the edit form:
  <span class="visualtag" x-char="&#x2009;">[lrm]&#x2009;</span>
where the CSS stylesheet used by the edit form defines:
  visualtag {
    border: 1px solid #00F;
    background: #EEF;
    color: #00F;
    padding: 1px;
    line-height: 1.2;
    font-size: 85%;
    font-weight:bold;
  }

This would apply as well to RIGHT-TO-LEFT MARK (rlm) U+200F:
  <span class="visualtag" x-char="&#x200F;">[rlm]&#x200F;</span>

Just like the NON-BREAKING SPACE (NBSP) U+00A0:
  <span class="visualtag" x-char="&#x00A0;">[nbsp]</span>

And the NARROW NON-BREAKING SPACE (NNBSP) U+2009 (alias "fine" in French):
  <span class="visualtag" x-char="&#x2009;">[nbthin]</span>

And the THIN SPACE (THINSP) U+200A (alias "ultrafine" in French, different as it is breakable, unlike from the French "fine"):
  <span class="visualtag" x-char="&#x200A;">[thin]</span>

And the ZERO-WIDTH JOINER (ZWJ) U+200D (needed in some orthographies):
  <span class="visualtag" x-char="&#x200D;">[zwj]</span>

And the ZERO-WIDTH NON-JOINER (ZWNJ) U+200C (needed in some orthographies):
  <span class="visualtag" x-char="&#x200C;">[zwnj]</span>

However, no tag should be used for the COMBINING GRAPHEME JOINER (CGJ) which is needed in extremely rares cases, but that will be used just before a non-combined diacritic (Unicode added it to block canonical reorderings), so that this diacritic would no longer display correctly if it was replaced by a visual tag, unless all the following diacritics are ALSO explicitly replaced as well with a visual tag (based on the dotted circle U+25CC ‎◌) like:
  <span class="visualtag" x-char="&#x0300;">&#x25CC;&#x0300;</span>

The Javascript in the HTML edit form should also be able to do the conversion between actual characters and visual tags in both directions (thanks to the x-char="..." attribute which hides the actual character that can be used when parsing the content of the HTML text area to locate all occurences of spans with class"visualtag"). This Javascript should also be able to detect when texts are copy-pasted containing strings like "[nbsp]" in order to replace them by the assiated visual tag: if one really wants to enter this text literally, he will need to type it character by character, and there will be a visual difference in the edit form.

This Javascript would then submit to the server only the converted characters. But if one enters the literal text in the edit form, the Javascript will not convert this text that will still be submitted literally to the server: the server will display a confirmation or another option to permit the conversion of apparent visual tags into their equivalent character by the server itself.