I will leave the task of finding cross db dependencies for someone else to write about as I am about to run out the door this morning but wanted to leave a quick note on sp_depends. It is broken, don't use it. It is notoriously unreliable. As per Microsoft "Use sys.dm_sql_referencing_entities and sys.dm_sql_referenced_entities instead" it is on the way out. Here is why sp_depends is broken, it relies on creation order. Say you have two stored procedures, ProcA and ProcB. ProcB depends on ProcA. If you create ProcA THEN create ProcB sp_depends will report the dependency, but due to support for late binding, if you create ProcB, THEN create ProcA sp_depends will NOT report the dependency.
For what it's worth there are a few tools I have used that do a great job of reporting dependencies properly but my favorite so far, and one that will deal with cross db dependencies if you have access to it is Visual Studio for Database Professionals. It's fairly spendy but if you have access to it is has an excellent dependencies tool and supports light refactoring, say you change the name of a column, it can find all views and procedures, even in multiple dbs and update the column name for you across your dependencies.
For a cheap single db GUI alternative ApexSql makes a nice tool. On the free side you could find or create a stored procedure to do the dependency checking for you but I don't have any links to help you out with that right now.