I think the usage of System.Core
may mean you run into some trouble (if only from a techy standpoint - IANAL so wouldn't comment on any sort of distribution issues)....
As an example (and I have no concrete evidence, just raising the hypothetical) you have the .NET 3.5 version of System.Core and there's a .NET 2.0 assembly which uses a class within System.Core but it has a wobbly because it's not the System.Core assembly which came with .NET 2.0 and may not behave the same way...or the reverse where something in the 3.5 System.Core expected that another one of the assemblies modified in .NET 3.5 does something a certain way or offers a certain function but the .NET 2.0 version of the assembly does not; it sounds like the kind of situation where you might invest quite a bit of time debugging/troubleshooting/diagnosing/head banging.
That being said it seems people have gotten it to work here and some previous SO questions here and here. There may also be some useful commentary in those links to help you along. Also some more links where people seem to be motivated by the same thing (using LINQ on .NET 2.0) here and here. And also some sort of implementation using assemblies from Mono here
It's one of those things that if you were just going to plop the assemblies in you'd want to (just my opinion) invest a fair amount of time in testing to reduce your risk footprint in terms of unpredictable results cropping up.
As you've noted, there wasn't a separate runtime between 2.0 and 3.5 (unlike from 2.0 -> 4.0) so using that fact could you get the latest 3.5 installed on each of the target machines your app will deploy to (desktops for a WinForms/WPF app or on the server for a web-based thing I guess) and just target 3.5 as your .NET version when developing in Visual Studio? That would make things a little safer I think as then you're actually targeting a Framework version as part of your dev effort rather than just swapping in/out a set of assemblies.