Also, just to add, RO in general is very finnicky with messing with items. The Client expect the item string in a very specific manner. It's essentially impossible to attach any persistent information to a item that does not fill up a existing slot.
However, there would be a actually feasible way to do this ( not saying that we will but .. )
One variable that gets always passed along with the item that is barely used at all is .. the Identified-switch. You could probably increase the max value of the identified value both within eA and the database into essentially any way you want, and then simply use those to store the enchantment status.
Additionally, it would still be possible to have them unidentified.
You could just create duplicate entries for every enchantment and have a modulo 2 run over it. If its even - its unids , if its odd its IDs.
As a example:
identified 0 - Not ID'd, No Effect.
identified 1 - ID'd, No Effect.
identified 2 - Not ID'd, STR +1.
identified 3 - ID'd, STR+1.
etc. Magnifier would only have to do: if identified = even , set identified +1;
I'm still not convinced whether it would be worth the efford, but using the system I outlined it should be pretty feasible and easy even.
The only problem would be how the client would react to a untypical ID'd value. What would likely happen is actually that the client would "loose" the custom ID value when picking it up. But with some hacking you might be able to have the client keep it.. hm. Ah well.