Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.
For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.
For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.