That sounds reasonable. If you want to run it ONCE after installation, you need to store state somewhere, to remember whether it got run or not. The file system is pretty much the only place you can store state. We could now argue whether the location /initialize is the best location for it; personally would look at the file system hierarchy for FreeBSD (see "man hier" or "man 7 hier") and then put the file in /usr/local/etc, but that's a small difference.
Minor simplifications (all of those are suggestions, and depend on personal style): Instead of calling it initialize.sh, just call it initialize. It's obvious that it is a shells script, from looking at the first line, don't need to repeat that fact. And then don't call it initialize (which is very ambigous), but "fumanchu_initializate" or "after_install_initialize" or something similarly descriptive. Since it is not a program that normal users use for productive work, but it's part of system administration, /usr/local/sbin might be a better location. To call it, you don't need to do "/bin/sh /usr/local/bin/initialize.sh", but you can put /bin/sh into the first line of the script itself (as a shebang line: "#!/bin/sh"), mark it as executable with "chmod a+x /usr/local/bin/initialize.sh", and call it directly from the .cshrc as "/usr/local/bin/initialize.sh" (without the /bin/sh in front), similar with the sudo line.
And one nasty question: So this initialize.sh script runs, and deletes the /initialize file. But what order do these operations happen in? For example, say that the first thing the initialize.sh script does it so delete the /initialize file, and then do its work. But what if the script crashes? It doesn't have to be it's own fault (a bug), it could be that power got turned off right in the middle of the script. From this bug, we learn that deleting /initialize has to be the last thing the script does, great. But now what happens when the script crashes halfway through? Sure, it will get restarted a second time, but the first half of its operations have already been done. So when you write that script, you need to think through it this way: It is a series of steps, each of which has to be atomic and idempotent. Atomic means the step either gets completely done or not at all, and there is no "halfway". Idempotent means it's OK to do the same step again even if it already got done, it won't do any harm. This is a specific example of what database people call "ACID" properties: Atomic, Consistent, Isolated, and Durable, with Idempotence being a good way to accomplish those in a transaction system.
