A lot of memory? Not at all, grasshopper.
The screen is 256X192, right? Well, storing the path in the absolute dumbest way possible would be 256X192 bitmap where each pixel is a single bit. So, that's 49152 bits, or 6144 bytes per path. That's not all, though, because this thing is going to be mostly zeroes, making it extremely easy to compress.
That's the dumb way. The smart way would be to have the user pick points on the path, and then connect them with an interpolated spline. I don't know if you're familiar with this drawing tool, but you can find it in most drawing programs, especially vector based ones. Basically, it's a way for the computer to connect the dots, smoothly. Giving the user the option of using that or straight line connect the dots, and they'll be able to make any path they like with no more than 3 or 4 points per path. Each point would be two bytes: one for the width (range of one unsigned byte = 256), and one for the height. The unused bits in the upper part of the height could be used to tell the AI whether that point is connected to the previous one by a spline or a sharp turn. Now, a football team has, what, 11 guys, right? Say that the devs place a limit of ten points per path (no particular reason other than that you should be able to get just about any path with that many points). That's 11*10*2 = 220 bytes per play. Now, considering that most of the players don't get told to do anything special (i.e. the linemen just block most of the time), the dev could let you spread the points out, say, giving more detailed instructions to the receivers.
Point being, there's plenty of room to let players make their own play books, especially if the dev compresses them (again, most of those points will probably go unused, and what's left should be highly compressible).
BlackGriffen