Nice questions!
Well, the answer to all of them depeneds on what you plan to do. The first you have to do is to evaluate if the effort needed to implement each pattern is worth the pain.
1)Are you going to switch between different implementations of forms and/or have massive unit tests for the UI alone? Then yes passive view seems a good idea.
2)Is it not so much pain to have a litle code inside the forms? Then MVP supervising controller can be faster to implement.
3)Can most of the logic of your program be inside bussiness layer? After you have all the logic inside BL, how much logic is GUI specific? If it is not that much then code inside the forms with no GUI patterns is the way to go.
About the questions:
1) Yes, EF can be considered a DAL, and doesn't hurt to be in a different project. Since you are into patterns, a usefull pattern here is Repository and Unit of Work Pattern that abstracts EF and lets you unit test the BL. (test without accessing an actual database, with a fake DAL implementation)
2) Depends. EF objects can be considered Data Transfer Objects since they are POCO. DTOs are visible in all layers. Another strategy is to have layer specific objects, mainly in the scenario of a tiered application (each layer in different machine).
If not forced to do otherwise, I would have EF objects visible to all layers but the DataContext itself visible only to BL, not GUI layer. This means that queries and transactions are done in BL but GUI can get the results in the same format.
3) If you follow the above advice, this rather bad object copying isn't needed.
4) This strategy you refer to is the Domain Model (google for more), in which you put logic inside the domain objects, that can also access the database. Again if you follow the advice in 2), this doesn't bother you.
Before getting frustrated around patterns and their correct implementations though, really focus on your needs! The goals are fast delivery and easy maintainance. Too much abstraction can hurt both!