This shouldn't actually cause a dependency on the object named by ObjectName (which may be in another package):

Schema.getGlobalDescribe().get(ObjectName).newSObject();

I am working on a prototype at the moment using this technique.

Actually, in my prototype I don't even have the base package installed in my packaging org - as in this prototype I wanted to see how far I could go avoiding any package dependencies. I have unmanaged proxy objects in my packaging org for test purposes, and these objects are not included in my package. The application can work with either unmanaged objects or managed packaged objects (naturally I need to prefix the namespace in the latter case).

This shouldn't actually cause a dependency on the object named by ObjectName (which may be in another package):

Schema.getGlobalDescribe().get(ObjectName).newSObject();

I am working on a prototype at the moment using this technique.

Actually, in my prototype I don't even have the base package installed in my packaging org - as in this prototype I wanted to see how far I could go avoiding any package dependencies. I have unmanaged proxy objects in my packaging org for test purposes, and these objects are not included in my package. The application can work with either unmanaged objects or managed packaged objects (naturally I need to prefix the namespace in the latter case).

So, this is essentially the same as Mock Custom Object in Andy's answer. In my case, rather than branching on Test.isRunningTest, I check for the namespace prefix in a (known) key in the global describe map, and the entire app switches between mock objects and actual managed objects - this means that apex tests succeed in either context.