Do you mean about using some other tool to actually manage db structure changes, like the xcase tool, then use DDT to manage deployment?
I'm not sure this will work.
I think the problem would be that the way DDT manages the deployment is by tracking all the changes you've made to the structure over time. It then can use this history to figure out what needs to be done to update any older version of the database to the current version. Without the history, I think this would either simply blow away the old database/objects within the database (not good) or fail because there are existing items within the database that the DDT isn't managing that have the same name (DDT adds extended properties to any object is manages).
So, I think the question is, can you use importing to update the structure within DDT in a way that would update the history of changes made. I.e. if you have a Customers table with two columns cust_pk and cust_name, then use xcase to add a third column, cust_city, if you import the resulting db back into DDT, will it have a history item indicating that a new column was added? I think you could run a test to figure this out, as you can view the history for a DDT project.
Even if this works, I think you would have to be careful in certain situations, like renaming columns. I.e. if you have a column named cust_zip, then realize that you need to use a non-US name for it and change it to cust_postalcode, the import would likely interpret this as deleting the cust_zip and adding a new column cust_postalcode, which would blow away any data during the upgrade. If this had been done in DDT, it would have known that a rename occurred and there would be no problem. Using an external tool, you likely have to to manage this via the pre script to rename the column yourself before running the DDT script (assuming this would work at all).
I use DDT to manage my security db, as it is just way too easy to keep the SF security tables updated via this method. However, my primary application db is not managed via DDT. I use a text editor to write the SQL scripts (kinda scary). I then use a tool called DbGhost to manage the deployment. It has the same issues you'd have with things like renaming columns or tables and it allows pre/post scripts. It can also manage synching data (like data in lookup tables). It isn't as nice as DDT in the sense that if you manage your structure within DDT, it will handle more db changes. However, I really like being able to check in my SQL script into source control and run diffs on them. Also, when I made this decision, the DDT didn't import sprocs or functions or maybe even triggers and it didn't use extended properties to allow non-DDT managed objects to coexist in the same database. I already had all the script, so it made sense to use another tool.
Hope that helped!