Fake PSI elements and the open type system

In Gosu we have something called The Open Type System (Cedric Beust recently blogged about it here: http://beust.com/weblog/2011/05/10/open-type-systems/) and we leverage this functionality heavily in Gosu.  As an example, Gosu comes with a properties type loader built in, which allows you to refer to properties in a Java properties file in a type safe way:

/src/tes/Foo.properties:
  AProp = Blah, Blah, Blah

/src/test/MyClass.gs:
  package test

  class MyClass {
    function foo() {
      print( test.Foo.AProp ) // <-- Compiles in Gosu because the properties file has a type in our type system, prints "Blah, Blah, Blah" at runtime
    }
  }

We would call the type 'test.Foo' a "synthetic" type: it isn't a bytecode type and the implementation of the 'AProp' static property

I'm curious how people think we should represent the 'AProp' static property reference.  It seems like ideally we would create a PSIType for 'test.Foo' and then PSIElements for the declaration-level stuff on that type (e.g. the 'AProp' property) so that things like finding usages work, etc.

Now, I realize that IntelliJ has support for properties and there are PSI Elements that I can look up somehow, and I'm interested in knowing how to do that.  But I'd also like to know how to handle the situation when that isn't the case, because some Gosu types don't have a file-based backing type, and even for the ones that do, I don't want people who create custom Gosu type loaders to also have to create an IntelliJ plugin just to get things like find references working, for example.

I'm thinking that we can just have a registry mapping Gosu type names to synthetic PsiClasses with synthetic PsiMethods, etc. on them that we maintain in the background, but if that sounds crazy or there is some other approach you'd recommend, I'm all ears.

Thanks for all your help,
Carson