EJBHome is the Factory that hands out and destroys EJBObjects. EJBObject is an intercepter that wraps business calls to your Bean and eventually delegates to your Bean implementation. They serve two very different purposes and are therefore rightly divided into separate interfaces. This is good design.
Back to the original question, writing one interface will never work. This is because there are certain rules and restrictions placed on EJB to allow the container to actually create the EJBObject. Remember the container is implementing EJBObject and EJBHome based on the interfaces and delegating to the EnterpriseBean object.
For EJBHome there are certain rules, every method in the interface must have a corresponding method prefixed by ejb in the EnterpriseBean. So if you have create() in EJBHome then you must have an ejbCreate() in the Bean class.
For EJBObject each method must directly have a corresponding method in the EnterpriseBean. So if you have getName() in EJBObject then getName() must be in the Bean class.
If your EJB fails these checks then it will be rejected by the container. Furthermore, these checks are such that it is pretty much impossible to use the same interface to extend both EJBHome and EJBObject.
Grammer aside, your solution is logically flawed. There are certains conditions that must be true to call a EJBObject method (object must exist, must have the Context set, must be in the ready pool, etc...), these same methods would also be available in the EJBHome if you used the same interface for both. What happens if someone calls a business method on the Home interface? It definitely not going to work, thats for sure, but what is to stop them? Or are you just going to promise not to? This means compile-time type checking goes out the window. Definitely not good.
Do the right thing and follow the spec, keep the responsibilities divided into separate classes (as said before, you couldn't combine them even if you wanted to).
