From a client view he/she does not want to be bothered with EJB exceptions but to just convert them to RuntimeException is bad as well because the client has still to deal with it (when you got a ticket you do not put them into the waste basket and think it is solved).
I suggest to create Client exceptions and then convert the EJB exceptions etc. to this client exceptions. If you cannot get a hold of services (NamingException) rethrow it as ServiceUnavailableException, when EJB is not found as InvalidSearchCriteriaException and so on. To make it a little bit simplier you can use attributes to reduce the number of exceptions and then let a client support class come up with a good explanation.
I like to distinguish between a 'technical exception' (NamingException, general Remote exception) which would result on the client side in something like a ServiceUnavailableException; and business exceptions. That means for the EJB business methods, define application specific, business-relevant exceptions which the client must deal with (at least because it will need to display a language-dependant meaningfull business error to the user).
Your access to the EJBs (at least for getting the home interfaces) should be encapsulated at a single point ("ServiceLocator pattern"); so the handling of the NamingException can be centralized there.
'Business Delegate' pattern is used for translating exceptions between business and presentation tier.
an RemoteException for example could have security reasons (wrong username or password)
or an entity bean could doesn't exist any more (is removed out of the database)
NoSuchObjectException, this could be a application exception that an account is delete for a user.
Think that none of the EJB/Remote Exceptions are real system or application exception they actually both.
Personally i think that you must deal with an exception or die.
i have seen to often that an exception is just catched and null is returned (very hard to find bugs).
an errorhandler interface like xml parser use may have some benefits to.
this is an very interesting topic (to much ignored)
howto handle exceptions