If you are planning to write a very parallel application in C#, is it better to build things very small, like
20 small classes, making 40 larger classes, and together making 60 more, for a total of 120
or gigantic like:
making these 60 classes individually (still with reusability in mind).
So in #2 these 60 classes can contain methods to do things instead of other classes.
Smaller pieces are easier to test, easier to refactor, and easier to maintain.
Abstractly, neither one of those approaches would make a difference.
Concretely, minimizing mutable state will make your application more paralellizable. Every time you change the state of an instance of your object, you create the potential for thread safety issues (either complexity, or bugs; choose at least one). If you look at Parallel LINQ or functional languages emphasizing parallelism, you'll notice that class design matters less than the discipline of avoiding changes in state.
Class design is for your sanity. Loosely coupled code makes you more sane. Immutable objects make you more parallel. Combine as needed.
It's not the size of the classes, but the scope of the coupling that matters.
For parallel applications, you should favor immutable objects---sometimes called "value objects" rather than objects with a lot of properties. If you need to apply operations that result in new values, just create new objects as the result.
Observe good separation of concerns, and let that lead you to the natural number of classes to represent the concepts in your program. I recommend the SOLID principles, cataloged and popularized by Robert Martin from ObjectMentor. (That should be enough Google-fodder to locate the list!)
Finally, I also recommend that you get intimate with both System.Threading and System.Collections. Most of the collections are not inherently thread safe, and synchronization is notoriously difficult to get right. So, you're better off using widely-used, tested, reliable synchronization primitives.