If I do have to implement a mapping for security, how would you
reccomend I map message values to points, and how should I figure out
the maximum message size based on my curve?
The default strategy for encoding an integer message as curve point is to define a value $k$ smaller than $\log_2 p$ (with $p$ being the field prime), such that for every valid message length $m$, $m+k< \log_2 p$ holds. You would then encode the message as the $m$ high bits of the x coordinate and start counting up on the $k$ low bits until you reach an $x$ that has an $y$ on the curve (which you find using the curve equation). This usually has probability $2^{-k}$ of failing to encode a message. For decoding you simply throw away the $k$ low bits and take the rest as your message.
Is my current implementation of the ElGamal part insecure because it
doesn't map messages and instead takes an integer?
Yes, the scheme as given is insecure because you can easily distinguish an encryption of $1$ from an encryption of $2^{1024}$ because the former will be about as long as the curve's prime and the latter will be more than 1024-bit long, which formally breaks the IND-CPA security of the scheme.
Note that in order to use proper ElGamal you need to encode your message as a curve point $M$ and then compute $c_1=[k]\beta+M, c_2=[k]G$ all as operations on the curve. Also note that I'm fairly confident that simply replacing the unbounded integer addition with integer addition $\bmod p$ will not yield security either because curve point coordinates are not uniformly chosen integers (for starters because some $x$ values simply do not occur).
Do I have to map a message, or is it possible to do something like
I've already got going with Edward's curves
I see no reason to make any changes to your code, because currently it doesn't actually use ElGamal (see above). If you were to use proper ElGamal, the same strategy that worked for Weierstrass should also work for Edwards (see the first part).