Important point. Not entirely sure of the most programmatic way to handle that. Seems like something anyone using Datascript would encounter so may be some advice to be had there.
Precept has helper functions that try to make it easy to convert to and from different tuple structures. I knew that would be an issue for adoption. The view always receives maps which is nice for React. They are “entity” maps they’re way easier to work with than relational vector tuples.
I think the biggest challenge is deciding the entities for your domain. Further I don’t think there’s a function we can write to do that for every domain. In the best case you might be renaming :id to :db/id. clojure.walk is nice for things like that 
Starting with a schema might help modeling. We have support for uniqueness and cardinality but no component attributes yet.
For better or worse we allow any? in the value slot, so you might be able to leverage that to marshal data that you additively tag with an eid / attribute to the view layer. A typical Precept app does this regularly (typically with accumulators) in order to fulfill subscriptions that the view needs.
There’s a post on reddit about the role of a more or less singular data format throughout the clojure stack when you’re using datomic and something like datascript or precept. Reddit - Dive into anything
This was a goal for Precept and part of why I felt parity with Datomic was important. You could use the same data structures from top to bottom, and have Precept on the server and/or the client, derive whatever data you need, and when it’s time to perform a write your data is already in the format the database expects.
I’m not against supporting more general “fact” formats, like Clara does with defrecords. Do you think that would help your situation?