Endnote uses a facility that was originally introduced in the early days of Word for Windows several decades ago to support the kinds of addin that existed at that time - I cannot remember specific names, but one class of addin were things such as Borland SideKick and Packrat that were known as "PIMs" (Personal Information Managers). They needed to save bits of information that could not easily be seen or modifed by the user.
The two fields used to do that were ADDIN and PRIVATE. I don't think either field is mentioned in the ISO29500 specifications for .docx. I think they both allowed you to store data using the field.data member, but also AFAICR using the .data member has been deprecated for some field types - if you use it and save a document, you may find that Word will not open it again. ADDIN fields are isible unless you or our code formats them as hidden. PRIVATE fields are hidden by default, like some other fields such as XE and TC fields.
other than that, EndNote and other Addins will use the .Code member of the field how they want (i.e. the text of the field, e.g. "ADDIN EN.CITE etc.", which will be visible if the user and the .Data member, which wouldn't be visible unless you looked at the underlying XML code for the Word document.) So stuff like EN.CITE is just text that EndNote inserts - EndNote does not have to register an "EN.CITE" code with Word or anything like that. All it has to do is ensure that the text that it adds to the field code does not result in any problems in Word and "round-trips@ successfully when Word - perhaps a different version or on a different platform - saves and opens the document.
ADDIN and PRIVATE fields aren't the only fields where you can add a lot of text - e.g. you can use
{ SET comment loads of text }
(I sometimes use it to document field coding).