The challenge with migrations is that it needs a full SQL query syntax for inspecting schema and modifying schema.  This is an area where our syntax differs from SQL Server in notable ways (which we are incrementally improving) and we don't have absolute coverage.  For example, some inspections and changes of schema require using our DDA interface.  This means we'd have a fair bit of unique engineering to support this that wouldn't be reusable with other data providers we support.

We plan on digging into this again post-VistaDB 5.1.  The big question for us is how useful EF 6 Code First is without Migrations - Migrations are a big block of unique functionality for us, whereas most of EF 6 Code First is just like standard EF from the provider standpoint. 

We've had folks tell us they can get queries to work with the providers as they are (since there is the ability to interrogate schema already built into the EF provider) so if you stay away from migrations (which can be disabled in Code First) you may find that everything else is working for you.  I know we've had some customers use it with success; our declarations saying that it isn't supported is really a function of us not having a test suite specifically for Code First which limits our ability to respond to support tickets on it.