The student's name field should only exist the student information table. You don't need to put copies of this data in any other table. With the correct relationships in place linking your other records by a StudentID, you can access and display the name field from student information on each of your other layouts. I would not use student names for match fields--even a grade school aged student's name can change during the course of a year so you don't want to rely on names to link records.
In most of your other tables, you probably will not need to autmatically create a record in that table until the first time that you need to record data for that student, at which time, you select the student via one of many interface options that you might use for selecting that student and the StudentID is entered into that table's new record to link it to the correct student.
The one exception here, is that you may find that you need one table for the student info and another for the list of students in each class. That might be necessary if there is any chance that the same student can attend two of your classes. In which case, you may need to import the student info and the student roster data as two separate imports--possibly from the same file of data from the schools data system.
And you can end up with two studentID fields--one from the school's system and one from your own database. I'd use a FileMaker generated serial number to uniquely identify each student and link them to related records in each of the tables I created. I'd keep the school supplied ID as a field in the student information table to use for reference purposes and to initially link records if I have to import data from the school's system into more than one table. That's to insulate your system from problems caused should the school every change the ID numbers or their format on you.