You're probably going to want at least one unit test assembly per assembly in the system.
You could argue that it might be worth splitting business logic tests into multiple test assemblies, say "BllTests.Customer, CllTests.Product, BllTests.Basket" etc.
The worst thing you can do is stick them all in one big assembly, it's the equivalent of having your entire project in one assembly: it makes things much harder to manage. Your test feedback will likely come from a Continuous Integration server, so you're going to want pretty pinpoint accuracy of what test is failing and what part of the system the test impacts, so you can make decisions about the impact of the failure itself.
You DEFINITELY don't want the tests in the same assembly as any production code. If you did put them all in with the production code you're going to have to deploy a bunch of 3rd party assemblies to your production server that have no use for the product itself and just add another possibly point of failure!
OK, so we're dealing with a monolith. This means you're unlikely to have interface abstraction (i.e. all the classes doing logic implementing an ILogicInterface, so you can test against interfaces instead of trying to run tests against concrete classes).
This is going to be a problem, you'll have to do tests without the standard approach of mocking the dependent interfaces (using something like Rhino mocks).
I'd suggest the best method for you is to start small: Make just a single assembly "BllTests.Customer". Then, slowly, move your implementation to inherit interfaces, starting right at the bottom of the code (abstracting your data access is a great start). Then unit test your small changes (we're talking about 4-5 methods inside a single class). Then pick the next small unit of logic and repeat.
When you've got a decent chunk of interface-inheriting code: start splitting your code into separate assemblies: "Bll.Implementation" and "Bll.Interfaces".
Progressive enhancement is the name of the game, there's little point trying to unit test spaghetti code, your unit tests will either be very brittle or not test enough paths through the code to make them useful indicators of whether you have a code problem.
If you can't edit the main codebase (not always an option), well, I'd still suggest the multiple test assembly approach. Try pushing for all new code to be made in separate assemblies, to avoid your monolith becoming even bigger. But in the meantime, show how a set of small, coherent assemblies can be much easier to manage: lead by example.