Count the lucky tickets within the given range
05AB1E, 8 (or 10?) 11 (or 13?) bytes
Ÿʒ₄n+¦S3ôOË

Try it online or verify some more test cases.
NOTE: In 05AB1E strings and integers are interchangeable, so the output numbers doesn't contain leading zeroes. This could however be fixed with 1 additional byte (12 bytes):
Ÿ₄n+€¦ʒS3ôOË

Try it online or verify some more test cases.
+3 bytes to bug-fix numbers with a length of 3 or less (range [000000, 000999]).
Explanation:

Ÿ          # Create an inclusive (on both sides) range from the two inputs
           #  i.e. 038920 and 038910 → 
           #   [38910,38911,38912,38913,38914,38915,38916,38917,38918,38919,38920]
 ʒ         # Filter this list by:
  ₄n+      #  Add 1,000,000 to the number
     |     #  And remove the leading 1
           #   i.e. 38910 → 1038910 → '038910'
  S        #  Transform it to a list of digits
           #   i.e. '038910' → ['0','3','8','9','1','0']
   3ô      #  Split it into chunks of length 3
           #   i.e. ['0','3','8','9','1','0'] → [['0','3','8'],['9','1','0']]
     O     #  Sum the digits in both parts
           #   i.e. [['0','3','8'],['9','1','0']] → [11,10]
      Ë    #  Check if they are equal (if they are, they remain in the filtered list)
           #   i.e. [11,10] → 0


EDIT: Seems I (and most other answers) slightly misread the challenge and the amount of numbers is being asked instead of the numbers themselves within the range. In that case a trailing }g can be added (close the filter; and get the amount of numbers left in the filtered list), so it's 10 13 bytes instead:
Ÿʒ₄n+¦S3ôOË}g

Try it online or verify some more test cases.