Hello and welcome to the forum.
First up, if you want an HTML export which is very different from what EA delivers, I think you're going to have to write your own. But I think what you describe can be achieved based on EA's built-in HTML generator.
I don't think XMI is the way forward. XMI is an OMG-standardized format, but large bits are outside the scope of the standard, and that includes the exact representation of the images. So EA's XMI image format, like every other modelling tool's, is proprietary and undocumented. Furthermore, I'm pretty sure that the image in the XMI format is just a bitmap with no reference to the elements it contains, so I don't think you could get a useful HTML page (with clickable elements) from an XMI file.
With EA's HTML exports you can modify the content that gets exported, but the fundamental structure is hard-coded in EA (and also undocumented). You can't change the file naming scheme, for instance. The actual clickability in the images is managed by a lot of JavaScript. You can modify this too if you like, but I don't think that'll get you very far either.
I think your best bet is to have EA generate the HTML, and then write your own set of pages which reference EA's and translate between your structure and EA's. Using the class name for a file name won't work though, because in EA having several classes of the same name in the same package is perfectly legal. In a file system, it is not.
The EA-generated HTML does contain a file per element. The reason the address bar doesn't change is that it is displayed in a separate frame, but if you check the frame properties you can see what file is being displayed in it. It will be something like ....../EARoot/EA1/EA7/EA105.html.
If you look into the EA-generated file structure, there's a top-level directory js/data full of XML files. You can use these to obtain translations between the names of the HTML files EA has generated and the names and GUIDs of the elements they contain.
HTH,
/Uffe