Based on this documentation here: http://docs.servicestack.net/physical-project-structure I wasn't able to quite figure out where \ how would be most appropriate to organize OrmLite within ServiceStack in order to have code-first structure and migrations etc.
Any suggestion what's would be best practice for this?
OrmLite works with dependency-free POCO (Plain old C# Objects) which can be maintained anywhere as you see fit depending on the complexity of your solution.
This answer explores the simplest approach of where you can reuse your DTOs for your OrmLite models. When your needs diverge and you need to separate your DTOs and your Data Models, e.g. more fields were added to the RDBMS table than you want to return, you can maintain them in your ServiceInterface implementation project.
When the complexity of your solution grows and you have other components that needs access to the Data Models independently from your Service implementation than you can move your OrmLite models in its own DataModel project. Note: Your "model" projects should have the minimum dependencies required and all your logic projects should be depending on them and not the other way around.