It sounds like you will need to use some other representation than the raw GPU-optimized data representation used by Away3D (which, after all, is a rendering engine and should be optimized for rendering quickly.)
I see this quite often, tool developers relying too heavily on the rendering engine’s internal structures. It’s the equivalence of having a TextField where you print out a date in some format, and having that as the only place and only format that the date is stored in. When you want to add a couple of days, or calculate the time difference between this date and another, you suddenly have to read the text field, and parse it into a date object, before you can use it to do what you want. This is an absurd approach of course, and the right way would be to persistently store the date object and only rely on the text field for displaying it, according to a mini-MVC pattern if you will.
The same should apply to your use of Away3D, in almost all cases. In game engines there’s a ton of information that should not be stored within Away3D (like game character health, weapon damage information, player name et c) and that seems reasonable. But the same applies even in some cases where you’re only working with geometry, so if you need information that is more about topology and less about rendering requirements, you should store that information yourself, e.g. by building a representation of your mesh with dedicated vertex and triangle objects. That way you can store the relationships between vertices and the triangles they belong to directly, and you can store the UV coordinates on the triangles, and handle transparently the fact that the same vertex object might point into several different locations in the Away3D vertices vector.
This way you have a data model (your representation) as well as the visual representation (the one in Away3D) and you never have to query the visual representation for data that is more readily available through your data model.
This requires some more memory, but it will be faster once you have built the data model, so that’s probably a trade off you’re ready to live with if you’re building mesh editing functionality (where fast topology operations are more important than memory usage.)