Gaussian: Relaxed scan with modredundant optimization and dummy atoms
Disclaimer: This answer concerns the use of Gaussian 09. While the ModRedundant interface is retained and therefore the same restrictions also apply in newer versions, there is now a newer way of using internal coordinates. See my other answer for this option.



Like I posted earlier in the comments, you can indeed not use dummy atoms with a relaxed scan via the ModRedundant interface, because they are not existent in that coordinate system. Internal redundant coordinates are generated only from actual atoms. I tried to find an explanation of that, but failed. I believe the reason for that behaviour is, that dummy atoms do not have basis functions and are therefore not included in the wave function.

In this case you need alternative means to what you actually want to achieve. That of course depends on what you would like to model. From the input you provided, I can see, that you are trying to move the middle points of the carbon-oxygen and nitrogen-hydrogen bonds closer together, possibly to simulate the carbon nitrogen bond formation and proton transfer. While I seriously doubt this will happen in one step, this is at least one way to try to go about it.

If this method had worked, I believe you would have gotten a different than expected result. There are some more issues, that you might have not considered with your approach.
You might think that the following two lines keep the nitrogen hydrogen bond distance fixed. They do not.

B 22 7 F
B 2 7 F


Because the bond angle A 22 7 2 is still flexible, and the bond length B 22 2 is still flexible, this can possibly do whatever it wants. The same does hold for the carbon oxygen bond.

B 6 19 F
B 21 19 F


If I am correct with my assumption, then what you want look at is the carbon nitrogen bond formation. Why not take this internal coordinate and scan it? It is easy and it should pretty much do what you like. The following input should take you there. Note that I changed the method to pm6 to massively cut down computer time - and even with that, it took to long for my patience. (I did also not include any trailing lines about resources - see my notes below.)


#P pm6
opt=(modredundant)
scrf=(pcm)
nosymm

4MeAminoButanal scan

0 1
C        0.000000     0.000000     0.000000
N        0.000000     0.000000     1.451901
C        1.325038     0.000000     2.055476
C        1.991320     1.377897     2.032970
C        1.229182     2.449098     2.809397
C        1.309917     2.335179     4.306919
H        1.218960    -0.323776     3.083767
H        1.990264    -0.714465     1.564774
H        2.993872     1.281489     2.436811
H        2.106328     1.711600     1.006802
H        1.602469     3.443240     2.566292
H        0.178120     2.455789     2.536445
H        0.708887     3.065770     4.854632
H       -1.016528    -0.113770    -0.358506
H        0.375985     0.943036    -0.379032
H        0.606031    -0.798850    -0.431982
O        1.974063     1.543637     4.907309
H       -0.496745    -0.808017     1.771266

B 6 17 F
B 2 18 F
B 2  6 S 60 -0.05



Also note, that I did not check that the N-C bond length will become shorter than an &Aring;ngstr&ouml;m, so the last steps take forever to converge and it will die in the last step running out of cycles. Run it with something more reasonable.
The calculation itself produced a somewhat reasonable result. The following animation cycles through all optimised structures. It was made with ChemCraft. 



Some more notes on your input:


%nprocshared=16 is quite a number you are requesting for a Hartree-Fock calculation. Consider that parallelisation is not linear. While it became better throughout the years, I guess 4 threads is the most reasonable for this system size. You can go higher, I'd not recommend to go above ten though. 
%mem=5gb is probably too much. I doubt that any of these processes will exceed 200MB of memory, probably a lot less. 
%chk=4MeAminoButanal You should consider adding the .chk ending in all cases. Gaussian is known to mess things up when there are non-ordinary characters like _-. in a file name.
It is maybe a good idea to not write the whole route section in one line. Consider this as improving the readability of your input.  You can cluster similar commands (like pop statements) in one line, etc..
In previous versions, Gaussian might have had trouble reading in anything beyond the  80th char. I cannot reproduce this bug anymore and it's been a long time since I was told about it, so this should not be an issue. However, a well structured input file can help you finding possible syntax errors that result from typos.