There is no support for composition or inheritance of SObjects.
Record types can sometimes be used instead: all possible fields are added to the SObject and subsets are presented (via different layouts) depending on the record type. All instances of the SObject have the same label, with the "Record Type" field presenting the different type names. But if this suits your needs it is very much a core platform feature.
Agreed that duplicating the code is a maintenance problem. If you do this, then you can use dynamic SOQL in your test class to avoid having to duplicate the tests for each SObject. You can cut and paste the .object files that the Force.com IDE makes available for each SObject to reduce copying errors. If there are only a few different SObjects I would take this approach.
You could move your complex logic to triggers and use methods such as SObject.get to access the data to keep the code independent of concrete SObjects. The shared code would be put into Apex classes and then the triggers for each new SObject type would delegate to those classes (so sharing the logic). But triggers are not a one for one replacement for formulas and can be hard to get right. I would only consider this approach if there were many different SObjects.