Don't use eval unless you have no other alternative. It is potentially dangerous, depending on the contents of the $start and $stop variables. It is not a good idea to get into the habit of using it where it isn't necessary.
Don't use the output of ls for anything but viewing in a terminal. Attempting to parse ls, even in the simplest fashion, can and will fail in all sorts of ways. Use anything that can produce a NUL-separated list of filenames instead: find -print0 is often a good choice.
The bash built-in {x..y} sequence expansion can't evaluate variables, but the standalone seq program can take variables as arguments. It also has a useful -s option to specify the separator.
The following requires a version of grep that supports the -z option for NUL-separated input records (e.g. GNU, FreeBSD, and most other modern versions of grep).
# build a regular expression matching the desired sequence
re="$(seq -s '|' "$start" "$stop")"
# use the RE with `find ... -print0` and `grep -E -z -c`
find /home/me/*/ -maxdepth 1 -type f -name 'file_*.txt' -print0 |
grep -Ezc "/file_($re)\.txt$"
For example, if start=3 and stop=7, then $re will be 3|4|5|6|7. The grep command would then expand to:
grep -Ezc "/file_(3|4|5|6|7)\.txt$"
BTW, the -name 'file_*.txt' arguments for the find command aren't required. They can be dropped, and the pipeline will still run without error. All they do is reduce the input data that needs to be processed by grep. A very minor optimisation at best.
e.g.
find /home/me/*/ -maxdepth 1 -type f -print0 | grep -Ezc "/file_($re)\.txt$"
wc -lto a variable which you initialize with 0.$startand$stopintegers or letters?| wc -lto afterdone, unless you also want to support filenames with embedded newlines (which your current code does not do).