This strikes me as the type of problem an programming instructor would use to convince programmers to analyze the situation before attempting to code.
First, there are only 9! ways the 9 digits can be selected. That is slightly less than 363K possibilities, not trillions as you suggest. But even that is a trap for the unwary.
Consider the first three digits. The lowest combination that sums to 15 is 1-5-9. This triplet contains the digits for six (3!) possible values that meet the criteria. If we record the triplets in ascending order of digits, there are only eight that satisfy the criteria: (1-5-9), (1-6-8), (2-4-9), (2-5-8), (2-6-7), (3-4-8), (3-5-7), and (4-5-6). Since each triplet represents six values, There only 48 possible values for the first three digits.
Considering the second set of three digits, the are also a max of 48 possible values but some of those have duplicate digits with the first set.
Once we have both sets, there are only three digits left to try an meet the final set of restrictions. There are six (3!) possibilities for those.
All in all, there are only 13,824 possibilities.
Now we just have to generate and test the possibilities. One approach could be:
Loop through the triplets. Call the selected one T1.
Loop through the triplets again. Call the selected one T2.
If no digits in common then:
Call the remaining three digits T3.
Loop through permutations of T1.
Loop through permutations of T2.
Loop through permutations of T3.
If all conditions satisfied then:
Export solution.
Next T3 permutation.
Next T2 permutation.
Next T1 permutation.
Next T2 selection.
Next T1 selection
Since most combinations of T1 and T2 will fail the digits-in-common test, relatively few permutations will actually be generated. The hardest part of the exercise will be writing a permutation routine that can handle multiple triplets and keep track of each one.