The assembly binary is stored as a blob in the database, so it's carried wherever the database goes. CLR is only enabled on the instance -- there are no database-specific settings for that.
In any event, why are you trying to do this?
(I'm not trying to be argumentative; I just want to hear the motives involved, because perhaps the problem could be solved in a different way that meets your needs.)
There's no way to do this easily, except to put the assembly in a shared database.
That said, I would think it's advantageous to embrace the database-centric architecture, unless there's a particular situation that has very compelling reasons to centralize. The reason why is that putting the assembly (or anything for that matter) outside the database creates a dependency in your environment. This is precisely the opposite approach Microsoft is building towards with Contained Databases starting in SQL Server 2012.
When you start needing to use features like replication or clustering, this dependency can potentially add a tremendous amount of complexity to the deployment, but also to troubleshooting, and failover procedures.
This architecture is much less obvious to people unfamiliar with the system (i.e., it's less self-discoverable, and less self-documenting).
If you end up requiring different security in different databases, or anything that involves variation, you're in a world of hurt.
If these databases get deployed to customers (sounds like they won't be, but I'll say this for completeness), this adds complexity to the deployment procedure, maintenance, and troubleshooting.
Since all databases would share this code, if any bugs are introduced (or fixed!), this could potentially break all the applications that rely on the databases. Comprehensive unit testing would be an absolute must.
If you have several databases that need the same functionality, there are other ways of reducing the amount of duplication involved, which I assume is the point of the exercise. Even a fairly complex CLR assembly won't take up much physical storage space compared to the data in the database itself (almost always), so I don't see that as a valid argument unless you have literally thousands of tiny databases that need this assembly.
What you could do is modify other parts of the deployment procedure for these databases to reduce the source duplication. For example, build and deploy the assembly from the common location of the CLR code in source control. Or, create a script that deploys the same assembly to the databases. Automate this part of things as much as possible, and it won't be a big deal.
I agree that what I'm suggesting is a tradeoff, because there will still be some duplication, but that has to be balanced with the negatives involved with implementing an architecture that doesn't follow the prescribed standard. Only you can decide what's right for your environment.