The problem is not with the code-first mentality; it is with a lack of awareness of what the defaults are when using code-first. I can build perfectly good 3NF tables using CF. In many ways CF is better than hand-rolled tables. By default the PK is called ID, the FK is called foreignTable_ID, table names are defaulted to plural or singular based on whatever you choose as the default, Clustered indexes are called IX_tableName, FK Check constraints are defined by default (so many DB devs don't do this when prototyping) and properly named, fields are NOT NULL by default unless you specify '?' on the end of the class property, values can be limited using an enumerator which requires a specific check constraint in SQL and going downstream to the presentation layer you can specify the default display names for the class properties which you can't do in SQL [this was one of the few nice features of Progress...]
CF also generates database snapshots and migration scripts that can be deployed through the release cycle and because you CAN define seed data, it can be much easier to make iterative changes whilst still in the DEV stage.
With CF you can rapidly prototype based on the business problem and then retro-fit the underlying data structure without having to touch the business logic or the entity classes.