WCF automatically generates serialization classes in memory for some communication protocols, mostly for XML communication, and seems to create a different class for each possible variation in the message structure; this easily explains the number of assemblies. This behavior is apparently normal for XML-based WCF protocols. If you have control over the protocol, switching to a non-XML communication protocol may resolve this problem.
The 3GB memory consumption is reasonable for this – the dynamic assembly will exist in both MSIL (.NET assembler language) and native versions in memory. The 150MB is probably for the MSIL version that was initially generated by WCF, and does not include the native code that gets generated by the .NET JIT compiler as soon as the MSIL version is “loaded” as a module and made callable.
The 17.45GB virtual space is not real memory, but instead is the distance between the lowest and highest memory locations where those modules get loaded; for example, if the main module loads at offset 0, and the first dynamic assembly loads at 00000000:0b000000, the total listed virtual memory will be about 185MB, even if the main module only takes 2MB and the dynamic assembly takes another 2MB. This is an exaggerated example, since they are usually packed in fairly well, but 1MB is typical between addresses, so 18000 * 1MB = 18000MB, which divided by 1024 gives exactly 17GB of address space (add another half GB for the rest of your system and you have the full virtual address space).
I have also seen one more type of fast-growing memory leak with WCF: if any part of a message is held by a persistent component of the application, the underlying XML COM object will not be garbage-collected, resulting in fairly large amounts of memory leaking. The .NET XML DOM uses the Windows COM XML subsystem, which is native code, and allocates on a native heap. This could explain the difference between managed and native memory heaps. Take a look at the actual memory in the dump (look for a tool that can filter out printable text), and check how much of it is formatted XML.
I have seen both of these leaks occur, and rapidly consume all of the memory on fairly large-scale servers, so I hope my experience provides an answer for you, or at least gives you some additional hints for tracing down your problem.