You can migrate a solution built in a D365 org to Dataverse, yes, but it carries risks, and I wouldn't advise it.
When you build a solution in an org that has a D365 solution, it becomes possible to accidentally create dependencies on that D365 content. If that happens, your solution will fail to import to a plain Dataverse Org because it is missing those D365 solutions.
For example, let's say the D365 app you've installed is CE. You have created a custom entity called "case tracking" and related it to the entity Case. Now you export your solution and go to import it into a Dataverse Org. Will it work? Maybe, but there is a decent chance it won't.
You see, Dataverse includes a base Common Data Schema that includes the Case entity so the simple fact that you created a relationship to Case doesn't break anything and if you added Case but absolutely no subcomponents from the entity, you can indeed import your solution into a normal Dataverse Org. But if you included any subcomponents at all from Case (a lookup field, perhaps? or some of the forms?), it becomes possible for you to accidentally pull in dependencies on customizations that exist only in CE, not in Dataverse. As a general rule, when managing solutions you always want to manage your content at the lowest, least-dependency level you possibly can so that you know you are never creating invalid builds. I would suggest, therefore, that you manage this solution in a normal Dataverse org, then port it to CE for testing.
The latest Dataverse documentation on solution management and planning is actually pretty decent and I suggest you give it a read to learn more about managed/unmanaged solutions and the strategies behind both.
